On Thu, 12 Oct 2000, Matthew Hawkins wrote:
> On 2000-10-11 12:48:54 -0400, Andrew Pimlott wrote:
> > No way should a desktop user be responsible for micro-managing the
> > resource usage of his applications.
>
> That's right. The systems administrator should, and will set
> appropriate limits f
On 2000-10-11 19:53:50 -0700, [EMAIL PROTECTED] wrote:
> On other machines I'd set RLIMIT_DATA and my OOM problems went away,
> but on linux this didn't work
RLIMIT_DATA appears to only be checked for aout format executables.
Looking at the 2.4.0-test10pre1 sources for fs/binfmt_aout.c and
fs/bin
I've had to support an app running as a back-end to a webserver that would
malloc() different amounts of memory depending on user input, up to
multiple gigabytes of memory which vastly exceeded the 512k the machine
had as main memory. The app was a program that would scan genetic
sequence lookin
On 2000-10-11 11:45:06 -0400, Bruce A. Locke wrote:
> This manpage shows me functions and structs.
What were you expecting from the system call section of the Linux
Programmer's Manual? Dancing girls?
(h...)
> I'm assuming you want these used by the offending program or the shell
> under w
On 2000-10-11 12:48:54 -0400, Andrew Pimlott wrote:
> No way should a desktop user be responsible for micro-managing the
> resource usage of his applications.
That's right. The systems administrator should, and will set
appropriate limits for users on his/her system that apply from login.
This
On Thu, 12 Oct 2000, Matthew Hawkins wrote:
> On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
> > Until user memory resource quotas are included in the kernel, there will be
> > nothing else that can be done. Even with resource quotas, if the total of
> > active users exceeds the resource then
On Thu, Oct 12, 2000 at 01:58:49AM +1100, Matthew Hawkins wrote:
> On 2000-10-11 10:33:39 -0400, Bruce A. Locke wrote:
> >
> > Your making the deadly assumption that all applications behave themselves
> > exactly the same all the time. Oops... netscape decided to freak out and
> > take up all yo
On Wed, 11 Oct 2000, Bruce A. Locke wrote:
> I wasn't aware PAM settings affected daemons started up during boottime
> but I will check into it, thank you.
>
daemons generally don't need to be PAM aware (unless they deal with
authorising things). The script that launches it however (if started
On Wed, 11 Oct 2000, Paul Jakma wrote:
> that's why you have per process limits set. Eg, PAM makes this
> exceedingly easy with pam_limit.so -> edit /etc/security/limit.conf.
>
> this prevents at least 90% of OOM situations (ie individual leaky
> processes). eg netscape will then pop-up "can not
On Thu, 12 Oct 2000, Matthew Hawkins wrote:
> Yep, for not setting appropriate resource limits.
>
> man 2 setrlimit
>
> Of course, if its a kernel bug that causes it I think you're SOL ;)
This manpage shows me functions and structs. I'm assuming you want these
used by the offending program or
- Received message begins Here -
>
> On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
> > Until user memory resource quotas are included in the kernel, there will be
> > nothing else that can be done. Even with resource quotas, if the total of
> > active users exceeds the res
On Thu, 12 Oct 2000, Matthew Hawkins wrote:
>
> Seriously, am I missing something obvious or is it far simpler just to
> keel over and die if the system goes OOM? I mean, seriously, if the
> administrator lets it get to that state then he/she/it deserves a dead
> system. It's akin to having yo
On 2000-10-11 10:33:39 -0400, Bruce A. Locke wrote:
>
> Your making the deadly assumption that all applications behave themselves
> exactly the same all the time. Oops... netscape decided to freak out and
> take up all your memory... guess its the admins fault.
Yep, for not setting appropriate
On Wed, 11 Oct 2000, Bruce A. Locke wrote:
>
> Your making the deadly assumption that all applications behave themselves
> exactly the same all the time. Oops... netscape decided to freak out and
> take up all your memory... guess its the admins fault. Oops... some
> mod_perl script decided to
On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
> Until user memory resource quotas are included in the kernel, there will be
> nothing else that can be done. Even with resource quotas, if the total of
> active users exceeds the resource then the same/equivalent situation occurs.
So setrlimit(
- Received message begins Here -
>
>
> Heh.. now all we need is some smart-arse to make something similar to
> apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy
> ;)
>
> Seriously, am I missing something obvious or is it far simpler just to
> keel over
Your making the deadly assumption that all applications behave themselves
exactly the same all the time. Oops... netscape decided to freak out and
take up all your memory... guess its the admins fault. Oops... some
mod_perl script decided to freak out and an apache process decides to suck
all o
Heh.. now all we need is some smart-arse to make something similar to
apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy
;)
Seriously, am I missing something obvious or is it far simpler just to
keel over and die if the system goes OOM? I mean, seriously, if the
administra
On Wed, Oct 11, 2000 at 11:08:41AM +0200, Helge Hafting wrote:
> Nothing wrong with a big init - the problem is a memory-leaking init.
> That one will die anyway, wether it dies early from an OOM-killer
> or later when all other processes are gone don't really matter.
Indeed.
Andrea
-
To unsubsc
Andrea Arcangeli wrote:
>
> On Tue, Oct 10, 2000 at 09:06:49AM +0200, Helge Hafting wrote:
> > If you want init to live - prove that it don't eat too much memory.
>
> I don't see why the machine should be stable only if init is small.
> My kernel won't be stable only if init is small since it do
On Tue, Oct 10, 2000 at 05:58:46PM -0300, Rik van Riel wrote:
> On Tue, 10 Oct 2000, Tom Rini wrote:
> > On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
> > > On Tue, 10 Oct 2000, Ingo Oeser wrote:
> > >
> > > > before you argue endlessly about the "Right OOM Killer (TM)", I
> > > >
On Tue, 10 Oct 2000, Tom Rini wrote:
> On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
> > On Tue, 10 Oct 2000, Ingo Oeser wrote:
> >
> > > before you argue endlessly about the "Right OOM Killer (TM)", I
> > > did a small patch to allow replacing the OOM killer at runtime.
> > >
>
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
> On Tue, 10 Oct 2000, Ingo Oeser wrote:
>
> > before you argue endlessly about the "Right OOM Killer (TM)", I
> > did a small patch to allow replacing the OOM killer at runtime.
> >
> > So now you can stop arguing about the one and o
Olaf Titz wrote:
>
> > > Still, it would be nice to recover that 4 MB when the system
> > > doesn't have any memory left.
> > Yup. The X server could give back the memory for some cases like the
> > background without too much hackery.
>
> Then Linux only needs to implement SIGDANGER, which has
On Tue, 10 Oct 2000, Rogier Wolff wrote:
>
> So if Netscape can "pump" 40 extra megabytes of memory out of X, this
> can be exploited.
>
> Now we're back to the point that a heuristic can never be right all
> the time..
I agree. In fact, we never left that.
Nothing is perfect.
In fact,
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
> > So now you can stop arguing about the one and only OOM killer,
> > implement it, provide it as module and get back to the important
> > stuff ;-)
>
> This is definately a cool toy for people who have doubts
> that my OOM killer wil
On Tue, Oct 10, 2000 at 12:30:51PM -0300, Rik van Riel wrote:
> Not killing init when we "should" definately prevents
> embedded systems from auto-rebooting when they should
> do so.
>
> (OTOH, I don't think embedded systems will run into
> this OOM issue too much)
but when they do, they're hard
On Tue, 10 Oct 2000, Ingo Oeser wrote:
> before you argue endlessly about the "Right OOM Killer (TM)", I
> did a small patch to allow replacing the OOM killer at runtime.
>
> So now you can stop arguing about the one and only OOM killer,
> implement it, provide it as module and get back to the i
On Tue, 10 Oct 2000, Philipp Rumpf wrote:
> On Tue, Oct 10, 2000 at 12:06:07PM -0300, Rik van Riel wrote:
> > On Tue, 10 Oct 2000, Philipp Rumpf wrote:
> > > > > The algorithm you posted on the list in this thread will kill
> > > > > init if on 4Mbyte machine without swap init is large 3 Mbytes
>
On Tue, Oct 10, 2000 at 12:06:07PM -0300, Rik van Riel wrote:
> On Tue, 10 Oct 2000, Philipp Rumpf wrote:
> > > > The algorithm you posted on the list in this thread will kill
> > > > init if on 4Mbyte machine without swap init is large 3 Mbytes
> > > > and you execute a task that grows over 1M.
>
On Tue, 10 Oct 2000, Philipp Rumpf wrote:
> > > The algorithm you posted on the list in this thread will kill
> > > init if on 4Mbyte machine without swap init is large 3 Mbytes
> > > and you execute a task that grows over 1M.
> >
> > This sounds suspiciously like the description of a DEAD syste
[OOM killer war]
Hi there,
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small patch to allow replacing the OOM killer at runtime.
You can even use modules, if you are careful (see khttpd on how
to do this without refcouting).
So now you can stop arguing about the one a
Linus Torvalds wrote:
> Basically, the only thing _I_ think X can do is to really say "oh, please
> don't count my memory, because everything I do I do for my clients, not
> for myself".
>
> THAT is my argument. Basically there is nothing we can reliably account.
>
> So we might as well fall ba
On Tue, Oct 10, 2000 at 09:06:49AM +0200, Helge Hafting wrote:
> If you want init to live - prove that it don't eat too much memory.
I don't see why the machine should be stable only if init is small.
My kernel won't be stable only if init is small since it doesn't cost
anything to handle correct
On Tue, Oct 10, 2000 at 04:38:02AM +0100, Philipp Rumpf wrote:
> Init should never die. If we get to do_exit in init we'll panic which is
> the right thing to do (reboot on critical systems).
If the page fault can fail with OOM on init, init will get a SIGSEGV while
running a signal handler (cop
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
> >
> > > I'd prefer just X having a higher "mm nice level" or something.
> >
> > Which it has, because:
> >
> > 1) CAP_RAW_IO
> > 2) p->euid == 0
>
> Oh, I agree, but we might want to generalize this a bit so
--On 09 October 2000, 17:40 -0300 Rik van Riel <[EMAIL PROTECTED]>
wrote:
> On Mon, 9 Oct 2000, James Sutherland wrote:
>> On Mon, 9 Oct 2000, Ingo Molnar wrote:
>> > On Mon, 9 Oct 2000, Rik van Riel wrote:
>> >
>> > > > so dns helper is killed first, then netscape. (my idea might not
>> > > > ma
Andreas Dilger wrote:
> Having a SIGDANGER handler is good for 2 reasons:
> 1) Lets processes know when memory is short so they can free needless cache.
> 2) Mark process with a SIGDANGER handler as "more important" than those
>without. Most people won't care about this, but init, and X, and
Albert D. Cahalan wrote:
> X, and any other big friendly processes, could participate in
> memory balancing operations. X could be made to clean out a
> font cache when the kernel signals that memory is low. When
> the situation becomes serious, X could just mmap /dev/zero over
> top of the backgr
On Mon, Oct 09, 2000 at 06:34:29PM -0300, Rik van Riel wrote:
> On Mon, 9 Oct 2000, Ingo Molnar wrote:
> > On Mon, 9 Oct 2000, Rik van Riel wrote:
> >
> > > Would this complexity /really/ be worth it for the twice-yearly OOM
> > > situation?
> >
> > the only reason i suggested this was the init=
> > Still, it would be nice to recover that 4 MB when the system
> > doesn't have any memory left.
> Yup. The X server could give back the memory for some cases like the
> background without too much hackery.
Then Linux only needs to implement SIGDANGER, which has been talked
about for years...
Andrea Arcangeli wrote:
>
> On Mon, Oct 09, 2000 at 08:42:26PM +0200, Ingo Molnar wrote:
> > ignoring the kill would just preserve those bugs artificially.
>
> If the oom killer kills a thing like init by mistake or init has a memleak
> you'll notice both problems regardless of having a magic fo
Andreas Dilger wrote:
> Albert D. Cahalan wrote:
> > X, and any other big friendly processes, could participate in
> > memory balancing operations. X could be made to clean out a
>
> Gerrit Huizenga wrote:
> > Anyway, there is/was an API in PTX to say (either from in-kernel or through
> > some us
> Rik van Riel wrote:
> > > How about SIGTERM a bit before SIGKILL then re-evaluate the OOM
> > > N usecs later?
> >
> > And run the risk of having to kill /another/ process as well ?
> >
> > I really don't know if that would be a wise thing to do
> > (but feel free to do some tests to see if your
> If init dies the kernel hangs solid anyway
Init should never die. If we get to do_exit in init we'll panic which is
the right thing to do (reboot on critical systems).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please
> (but I'd be curious if somebody actually manages to
> trick the OOM killer into killing init ... please
> test a bit more to see if this really happens ;))
In a non-real-world situation, yes. (mem=3500k, many drivers, init=/bin/bash,
tried to enter a command). Since the process in question (b
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> Date: Mon, 9 Oct 2000 19:13:25 -0400 (EDT)
>
> >> From: Linus Torvalds <[EMAIL PROTECTED]>
>
> >> One of the biggest bitmaps is the background bitmap. So you have a
> >> client that uploads it to X and then goes away. There's nobody to
> >> un-c
On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> > If the oom killer kills a thing like init by mistake
> That only happens in the "random" OOM killer 2.2 has ...
[OOM killer war]
Hi there,
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small patch to allow
On Mon, 9 Oct 2000, Albert D. Cahalan wrote:
> Jim Gettys writes:
> >> From: Linus Torvalds <[EMAIL PROTECTED]>
>
> >> One of the biggest bitmaps is the background bitmap. So you have a
> >> client that uploads it to X and then goes away. There's nobody to
> >> un-count to by the time X decides t
Jim Gettys writes:
>> From: Linus Torvalds <[EMAIL PROTECTED]>
>> One of the biggest bitmaps is the background bitmap. So you have a
>> client that uploads it to X and then goes away. There's nobody to
>> un-count to by the time X decides to switch to another background.
>
> Actually, the big off
On Tue, 10 Oct 2000, bert hubert wrote:
> On Mon, Oct 09, 2000 at 02:38:10PM -0700, Linus Torvalds wrote:
>
> > So the process that gave X the bitmap dies. What now? Are we going to
> > depend on X un-counting the resources?
> >
> > I'd prefer just X having a higher "mm nice level" or something.
On Mon, 9 Oct 2000, Byron Stanoszek wrote:
> On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
>
> > Anyway, there is/was an API in PTX to say (either from in-kernel or through
> > some user machinations) "I Am a System Process". Turns on a bit in the
> > proc struct (task struct) that made it exempt
On Mon, Oct 09, 2000 at 02:38:10PM -0700, Linus Torvalds wrote:
> So the process that gave X the bitmap dies. What now? Are we going to
> depend on X un-counting the resources?
>
> I'd prefer just X having a higher "mm nice level" or something.
I wonder how many megabytes we can fill with all m
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
> Anyway, there is/was an API in PTX to say (either from in-kernel or through
> some user machinations) "I Am a System Process". Turns on a bit in the
> proc struct (task struct) that made it exempt from death from a variety
> of sources, e.g. OOM, gen
At Sequent, we found that there are a small set of processes which are
"critical" to the system's operation in that they should not be killed
on swap shortage, memory shortage, etc. This included things like init,
potentially inetd, the swapper, page daemon, clusters heartbeat daemon,
and genera
i <[EMAIL PROTECTED]>,
> Rik van Riel <[EMAIL PROTECTED]>,
> Byron Stanoszek <[EMAIL PROTECTED]>,
> MM mailing list <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
> -
> On
On Mon, 9 Oct 2000, Aaron Sethman wrote:
> I think the run time should probably be accounted into to this
> as well. Basically start knocking off recent processes first,
> which are likely to be childless, and start working your way up
> in age.
I'm almost getting USENET flashbacks ... ;)
Plea
> > across AF_UNIX sockets so the mechanism is notionally there to provide the
> > credentials to X, just not to use them
>
> The problem is that there is no way to keep track of them afterwards.
If you use mmap for your allocator then beancounter will get it right. Every
resource knows which b
On Mon, 9 Oct 2000, James Sutherland wrote:
> On Mon, 9 Oct 2000, Ingo Molnar wrote:
>
> > On Mon, 9 Oct 2000, Rik van Riel wrote:
> >
> > > > so dns helper is killed first, then netscape. (my idea might not
> > > > make sense though.)
> > >
> > > It makes some sense, but I don't think OOM is
On Mon, 9 Oct 2000, Jim Gettys wrote:
>
>
> On Date: Mon, 9 Oct 2000 14:38:10 -0700 (PDT), Linus Torvalds
><[EMAIL PROTECTED]>
> said:
>
> >
> > The problem is that there is no way to keep track of them afterwards.
> >
> > So the process that gave X the bitmap dies. What now? Are we going t
On Date: Mon, 9 Oct 2000 14:38:10 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]>
said:
>
> The problem is that there is no way to keep track of them afterwards.
>
> So the process that gave X the bitmap dies. What now? Are we going to
> depend on X un-counting the resources?
>
X has to un
On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > I'd prefer just X having a higher "mm nice level" or something.
>
> Which it has, because:
>
> 1) CAP_RAW_IO
> 2) p->euid == 0
Oh, I agree, but we might want to generalize this a bit so that root could
say "this process is important" and then drop
> > Sounds like one needs in addition some mechanism for servers to "charge"
> clients for
> > consumption. X certainly knows on behalf of which connection resources
> > are created; the OS could then transfer this back to the appropriate client
> > (at least when on machine).
>
> Definitely - a
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> On Mon, 9 Oct 2000, Alan Cox wrote:
> > > consumption. X certainly knows on behalf of which connection resources
> > > are created; the OS could then transfer this back to the appropriate client
> > > (at least when on machine).
> >
> > Definitely - and
On Mon, 9 Oct 2000, Alan Cox wrote:
> > consumption. X certainly knows on behalf of which connection resources
> > are created; the OS could then transfer this back to the appropriate client
> > (at least when on machine).
>
> Definitely - and this is present in some non Unix OS's. We do pass c
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > Would this complexity /really/ be worth it for the twice-yearly OOM
> > situation?
>
> the only reason i suggested this was the init=/bin/bash, 4MB
> RAM, no swap emergency-bootup case. We must not kill init i
On Mon, Oct 09, 2000 at 10:28:38PM +0100, Alan Cox wrote:
> > Sounds like one needs in addition some mechanism for servers to "charge" clients
>for
> > consumption. X certainly knows on behalf of which connection resources
> > are created; the OS could then transfer this back to the appropriate c
On Mon, 9 Oct 2000, David Ford wrote:
> Not if "init" is a particular program running on a router floppy for
> example. The system may be designed to be a router and the userland
> monitor/control program is the only thing that runs and consumes 90% of the
> memory. If a forked or spawned proce
On Mon, 9 Oct 2000, Rik van Riel wrote:
> Would this complexity /really/ be worth it for the twice-yearly OOM
> situation?
the only reason i suggested this was the init=/bin/bash, 4MB RAM, no swap
emergency-bootup case. We must not kill init in that case - if the current
code doesnt then great
> Sounds like one needs in addition some mechanism for servers to "charge" clients for
> consumption. X certainly knows on behalf of which connection resources
> are created; the OS could then transfer this back to the appropriate client
> (at least when on machine).
Definitely - and this is pres
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Alan Cox wrote:
>
> > Lets kill a 6 week long typical background compute job because
> > netscape exploded (and yes netscape has a child process)
>
> in the paragraph you didnt quote i pointed this out and
> suggested adding all parent
rea Arcangeli <[EMAIL PROTECTED]>,
> Rik van Riel <[EMAIL PROTECTED]>,
> Byron Stanoszek <[EMAIL PROTECTED]>,
> MM mailing list <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
>
On Mon, 9 Oct 2000, Alan Cox wrote:
> Lets kill a 6 week long typical background compute job because
> netscape exploded (and yes netscape has a child process)
in the paragraph you didnt quote i pointed this out and suggested adding
all parent's badness value to children as well - so we'd end u
> i think the OOM algorithm should not kill processes that have
> child-processes, it should first kill child-less 'leaves'. Killing a
> process that has child processes likely results in unexpected behavior of
> those child-processes. (and equals to effective killing of those
> child-processes as
> Then spam the console loudly with printk, but don't destroy the whole machine.
> Init should only get killed if it REALLY is taking a lot of memory. On a 4 or 8meg
If init dies the kernel hangs solid anyway
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> On Mon, 9 Oct 2000, Andi Kleen wrote:
> >
> > netscape usually has child processes: the dns helper.
>
> Yeah.
>
> One thing we _can_ (and probably should do) is to do a per-user
> memory pressure thing - we have easy access to the "struct
> user_stru
On Mon, Oct 09, 2000 at 01:52:21PM -0700, Linus Torvalds wrote:
> One thing we _can_ (and probably should do) is to do a per-user memory
> pressure thing - we have easy access to the "struct user_struct" (every
> process has a direct pointer to it), and it should not be too bad to
> maintain a per
On Mon, 9 Oct 2000, Andi Kleen wrote:
>
> netscape usually has child processes: the dns helper.
Yeah.
One thing we _can_ (and probably should do) is to do a per-user memory
pressure thing - we have easy access to the "struct user_struct" (every
process has a direct pointer to it), and it sho
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> I disagree - if we start adding these kinds of heuristics to it, it
> wil just be a way for people to try to confuse the OOM code. Imagine
> some bad guy that does 15 fork()'s and then tries to OOM...
yep.
Ingo
-
To unsubscribe from this lis
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> On Mon, 9 Oct 2000, Ingo Molnar wrote:
> >
> > i think the OOM algorithm should not kill processes that have
> > child-processes, it should first kill child-less 'leaves'. Killing a
> > process that has child processes likely results in unexpected behav
Rik van Riel wrote:
> > How about SIGTERM a bit before SIGKILL then re-evaluate the OOM
> > N usecs later?
>
> And run the risk of having to kill /another/ process as well ?
>
> I really don't know if that would be a wise thing to do
> (but feel free to do some tests to see if your idea would
> w
On Mon, Oct 09, 2000 at 09:38:08PM +0100, James Sutherland wrote:
> Shouldn't the runtime factor handle this, making sure the new process is
The runtime factor in the algorithm will make the first difference
only after lots lots of time (and the run_time can as well be wrong
because of jiffies wr
On Mon, 9 Oct 2000, James Sutherland wrote:
> On Mon, 9 Oct 2000, Ingo Molnar wrote:
> > On Mon, 9 Oct 2000, Rik van Riel wrote:
> >
> > > > so dns helper is killed first, then netscape. (my idea might not
> > > > make sense though.)
> > >
> > > It makes some sense, but I don't think OOM is some
On Mon, 9 Oct 2000, Ingo Molnar wrote:
>
> i think the OOM algorithm should not kill processes that have
> child-processes, it should first kill child-less 'leaves'. Killing a
> process that has child processes likely results in unexpected behavior of
> those child-processes. (and equals to eff
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > > so dns helper is killed first, then netscape. (my idea might not
> > > make sense though.)
> >
> > It makes some sense, but I don't think OOM is something that
> > occurs often enough to care about it /that
On Mon, 9 Oct 2000, David Ford wrote:
> Ingo Molnar wrote:
>
> > > a good idea to have SIGKILL delivery speeded up for every SIGKILL ...
> >
> > yep.
>
> How about SIGTERM a bit before SIGKILL then re-evaluate the OOM
> N usecs later?
And run the risk of having to kill /another/ process as well
Ingo Molnar wrote:
> > a good idea to have SIGKILL delivery speeded up for every SIGKILL ...
>
> yep.
How about SIGTERM a bit before SIGKILL then re-evaluate the OOM N usecs
later?
-d
--
"There is a natural aristocracy among men. The grounds of this are
virtue and talents", Thomas
Rik van Riel wrote:
> On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> > On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> > > No. It's only needed if your OOM algorithm is so crappy that
> > > it might end up killing init by mistake.
> >
> > The algorithm you posted on the list in thi
On Mon, Oct 09, 2000 at 05:06:48PM -0300, Rik van Riel wrote:
> On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> > On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> > > No. It's only needed if your OOM algorithm is so crappy that
> > > it might end up killing init by mistake.
> >
> > T
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > > so dns helper is killed first, then netscape. (my idea might not
> > > make sense though.)
> >
> > It makes some sense, but I don't think OOM is something that
> > occurs often enough to care about it /that/
On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> On Mon, Oct 09, 2000 at 10:06:02PM +0200, Ingo Molnar wrote:
> > i think the OOM algorithm should not kill processes that have
> > process that has child processes likely results in unexpected behavior of
>
> You just know what I think about those heu
On Mon, 9 Oct 2000, Rik van Riel wrote:
> > so dns helper is killed first, then netscape. (my idea might not
> > make sense though.)
>
> It makes some sense, but I don't think OOM is something that
> occurs often enough to care about it /that/ much...
i'm trying to handle Andrea's case, the in
Andrea Arcangeli wrote:
> On Mon, Oct 09, 2000 at 12:30:20PM -0700, David Ford wrote:
> > Init should only get killed if it REALLY is taking a lot of memory. On a 4 or 8meg
>
> Init should never get killed. Killing init can be compared to destroy the TCP
> stack. Some app can keep to run right f
On Mon, 9 Oct 2000, Rik van Riel wrote:
> Note that the OOM killer already has this code built-in, but it may be
oops, i didnt notice (really!). One comment: 5*HZ in your code is way too
much for counter, and it might break the scheduler in the future. (right
now those counter values are unused
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Andi Kleen wrote:
>
> > netscape usually has child processes: the dns helper.
>
> so dns helper is killed first, then netscape. (my idea might not
> make sense though.)
It makes some sense, but I don't think OOM is something that
occu
On Mon, Oct 09, 2000 at 10:06:02PM +0200, Ingo Molnar wrote:
> i think the OOM algorithm should not kill processes that have
> process that has child processes likely results in unexpected behavior of
You just know what I think about those heuristics. I think all we need is a
per-task pagefault/a
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> what do you think about the attached patch? It increases the effective
> priority of a (kernel-) killed process, and initiates a reschedule, so
> that it gets selected ASAP. (except if there are RT processes around.)
> This should make OOM decisions 'visib
On Mon, 9 Oct 2000, Andi Kleen wrote:
> netscape usually has child processes: the dns helper.
so dns helper is killed first, then netscape. (my idea might not make
sense though.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> > No. It's only needed if your OOM algorithm is so crappy that
> > it might end up killing init by mistake.
>
> The algorithm you posted on the list in this thread will kill
> init if on
On Mon, 9 Oct 2000, David Ford wrote:
> Then spam the console loudly with printk, but don't destroy the
> whole machine. Init should only get killed if it REALLY is
> taking a lot of memory. On a 4 or 8meg machine tho, the
> probability of init getting killed is simply too high for
> comfort. I
1 - 100 of 130 matches
Mail list logo
