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
> 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
> 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
>
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
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
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
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
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
>
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
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, 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
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
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
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
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.
> >
> >
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
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
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
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
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
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
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
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
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
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.
On Mon, Oct 09, 2000 at 10:06:02PM +0200, Ingo Molnar wrote:
>
> On Mon, 9 Oct 2000, Andrea Arcangeli 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
Rik,
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 'visible' much more quickly.
Ingo
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 for some minute until they run
On Mon, 9 Oct 2000, Andrea Arcangeli 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 4Mbyte machine without swap init is large 3 Mbytes and you
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 4Mbyte
machine without swap init is large 3 Mbytes and
On Mon, 9 Oct 2000, Rik van Riel wrote:
> On Mon, 9 Oct 2000, Marco Colombo wrote:
> > On Fri, 6 Oct 2000, Rik van Riel wrote:
> >
> > [...]
> > > They are niced because the user thinks them a bit less
> > > important.
> >
> > Please don't, this assumption is quite wrong. I use nice just to
>
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 have never ever seen init start consuming
Here's an idea, farfetched as it may be.
Page the entire process out to disk into a user defined area, SIGHALT it and use
printk or a kthread/userproc to notify the user that something was kicked out of
the sandbox for playing bad. The user can add more swap if desired, then use a
userland tool
Rik van Riel wrote:
> On Mon, 9 Oct 2000, Marco Colombo wrote:
> > On Fri, 6 Oct 2000, Rik van Riel wrote:
> >
> > [...]
> > > They are niced because the user thinks them a bit less
> > > important.
> >
> > Please don't, this assumption is quite wrong. I use nice just to
> > be 'nice' to other
On Mon, 9 Oct 2000, Rik van Riel wrote:
> > yes. Please remove the above part.
>
> OK, done.
thanks - i think all the other heuristics are 'fair': processes with more
CPU and run time used are likely to be more important, superuser processes
and direct-hw-access processes ditto.
Ingo
On Mon, 9 Oct 2000, 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
That only happens in the "random" OOM killer 2.2 has ...
> So
Rik van Riel wrote:
> On Mon, 9 Oct 2000, Marco Colombo wrote:
> > On Fri, 6 Oct 2000, Rik van Riel wrote:
> >
> > [...]
> > > They are niced because the user thinks them a bit less
> > > important.
> >
> > Please don't, this assumption is quite wrong. I use nice just to
> > be 'nice' to other
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 for init in a _very_
slow path so I
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> > If you have a better algorithm, feel free to send patches.
>
> yes. Please remove the above part.
OK, done.
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/
On Mon, 9 Oct 2000, Rik van Riel wrote:
> In that case the time the process has been running and the
> CPU time used will save the process if it's been running for
> a long time.
'importance' is not something we can measure reliably within the kernel.
And assuming that a niced, not
On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> On Fri, Oct 06, 2000 at 04:19:55PM -0400, Byron Stanoszek wrote:
> > In the OOM killer, shouldn't there be a check for PID 1 just to enforce that
>
> Init can't be killed in 2.2.x latest, the same bugfix should be forward
> ported to 2.4.x.
I
On Fri, Oct 06, 2000 at 04:19:55PM -0400, Byron Stanoszek wrote:
> In the OOM killer, shouldn't there be a check for PID 1 just to enforce that
Init can't be killed in 2.2.x latest, the same bugfix should be forward
ported to 2.4.x.
> Can you give me your rationale for selecting 'nice'
Kurt Garloff wrote:
> I could not agree more. Normally, you'd better kill a foreground task
> (running nice 0) than selecting one of those background jobs for some
> reasons:
> * The foreground job can be restarted by the interactive user
> (Most likely, it will be only netscape anyway)
> * The
On Mon, 9 Oct 2000, Marco Colombo wrote:
> On Fri, 6 Oct 2000, Rik van Riel wrote:
>
> [...]
> > They are niced because the user thinks them a bit less
> > important.
>
> Please don't, this assumption is quite wrong. I use nice just to
> be 'nice' to other users. I can run my *important* CPU
On Mon, 9 Oct 2000, Marco Colombo wrote:
> [...]
> > They are niced because the user thinks them a bit less
> > important.
>
> Please don't, this assumption is quite wrong. I use nice just to be
> 'nice' to other users. I can run my *important* CPU hog simulation
> nice +10 in order to let
On Mon, Oct 09, 2000 at 12:12:02PM +0200, Marco Colombo wrote:
> On Fri, 6 Oct 2000, Rik van Riel wrote:
> [...]
> > They are niced because the user thinks them a bit less
> > important.
>
> Please don't, this assumption is quite wrong. I use nice just to be
> 'nice' to other users. I can run
On Mon, 9 Oct 2000, Marco Colombo wrote:
> On Fri, 6 Oct 2000, Rik van Riel wrote:
>
> [...]
> > They are niced because the user thinks them a bit less
> > important.
>
> Please don't, this assumption is quite wrong. I use nice just to be
> 'nice' to other users. I can run my *important* CPU
On Fri, 6 Oct 2000, Rik van Riel wrote:
[...]
> They are niced because the user thinks them a bit less
> important.
Please don't, this assumption is quite wrong. I use nice just to be
'nice' to other users. I can run my *important* CPU hog simulation
nice +10 in order to let other people get
On Fri, 6 Oct 2000, Rik van Riel wrote:
[...]
They are niced because the user thinks them a bit less
important.
Please don't, this assumption is quite wrong. I use nice just to be
'nice' to other users. I can run my *important* CPU hog simulation
nice +10 in order to let other people get
On Mon, 9 Oct 2000, Marco Colombo wrote:
On Fri, 6 Oct 2000, Rik van Riel wrote:
[...]
They are niced because the user thinks them a bit less
important.
Please don't, this assumption is quite wrong. I use nice just to be
'nice' to other users. I can run my *important* CPU hog
On Mon, Oct 09, 2000 at 12:12:02PM +0200, Marco Colombo wrote:
On Fri, 6 Oct 2000, Rik van Riel wrote:
[...]
They are niced because the user thinks them a bit less
important.
Please don't, this assumption is quite wrong. I use nice just to be
'nice' to other users. I can run my
On Mon, 9 Oct 2000, Marco Colombo wrote:
On Fri, 6 Oct 2000, Rik van Riel wrote:
[...]
They are niced because the user thinks them a bit less
important.
Please don't, this assumption is quite wrong. I use nice just to
be 'nice' to other users. I can run my *important* CPU hog
Kurt Garloff wrote:
I could not agree more. Normally, you'd better kill a foreground task
(running nice 0) than selecting one of those background jobs for some
reasons:
* The foreground job can be restarted by the interactive user
(Most likely, it will be only netscape anyway)
* The
On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
On Fri, Oct 06, 2000 at 04:19:55PM -0400, Byron Stanoszek wrote:
In the OOM killer, shouldn't there be a check for PID 1 just to enforce that
Init can't be killed in 2.2.x latest, the same bugfix should be forward
ported to 2.4.x.
I believe we
On Mon, 9 Oct 2000, Ingo Molnar wrote:
If you have a better algorithm, feel free to send patches.
yes. Please remove the above part.
OK, done.
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/
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 for init in a _very_
slow path so I
Rik van Riel wrote:
On Mon, 9 Oct 2000, Marco Colombo wrote:
On Fri, 6 Oct 2000, Rik van Riel wrote:
[...]
They are niced because the user thinks them a bit less
important.
Please don't, this assumption is quite wrong. I use nice just to
be 'nice' to other users. I can run my
On Mon, 9 Oct 2000, 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
That only happens in the "random" OOM killer 2.2 has ...
So you
Rik van Riel wrote:
On Mon, 9 Oct 2000, Marco Colombo wrote:
On Fri, 6 Oct 2000, Rik van Riel wrote:
[...]
They are niced because the user thinks them a bit less
important.
Please don't, this assumption is quite wrong. I use nice just to
be 'nice' to other users. I can run my
Here's an idea, farfetched as it may be.
Page the entire process out to disk into a user defined area, SIGHALT it and use
printk or a kthread/userproc to notify the user that something was kicked out of
the sandbox for playing bad. The user can add more swap if desired, then use a
userland tool
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 have never ever seen init start consuming
On Mon, 9 Oct 2000, Rik van Riel wrote:
On Mon, 9 Oct 2000, Marco Colombo wrote:
On Fri, 6 Oct 2000, Rik van Riel wrote:
[...]
They are niced because the user thinks them a bit less
important.
Please don't, this assumption is quite wrong. I use nice just to
be 'nice' to
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 4Mbyte
machine without swap init is large 3 Mbytes and
On Mon, 9 Oct 2000, Andrea Arcangeli 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 4Mbyte machine without swap init is large 3 Mbytes and you execute
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 for some minute until they run
Rik,
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 'visible' much more quickly.
Ingo
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 4Mbyte
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 'visible'
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
occurs
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
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 for
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
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
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/ much...
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.
The algorithm
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
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 ?
I
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/ much...
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 something that
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
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 behavior of
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 list:
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
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
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_struct" (every
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
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 up
iel [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, Oct 09, 2000 at 01:52:21PM -0700, Linus Torvalds wrote:
One thing we _can_ (and probably should do
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's
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 present
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
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 process
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 client
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
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 this is
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
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 root
101 - 200 of 229 matches
Mail list logo
