Stephen Clouse wrote:
> We run Oracle on a development box here, and it's always the first to get the
> axe (non-root process using 70-80 MB VM). ...
> It would be nice to give immunity to certain uids, ...
It would seem to me that the new capabilities stuff _could_ be the answer.
Basically,
On Sat, Mar 24, 2001 at 02:54:55AM -0300, Rik van Riel wrote:
> On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
> > - trying to kill a task that is permanently in TASK_UNINTERRUPTIBLE
> >will probably deadlock the machine [or the random OOM killer will
> >kill the box].
>
> This could
On Sat, Mar 24, 2001 at 02:54:55AM -0300, Rik van Riel wrote:
On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
- trying to kill a task that is permanently in TASK_UNINTERRUPTIBLE
will probably deadlock the machine [or the random OOM killer will
kill the box].
This could indeed be
Stephen Clouse wrote:
We run Oracle on a development box here, and it's always the first to get the
axe (non-root process using 70-80 MB VM). ...
It would be nice to give immunity to certain uids, ...
It would seem to me that the new capabilities stuff _could_ be the answer.
Basically, all
Alan Cox wrote:
>
> > >How do you return an out of memory error to a C program that is out of memory
> > >due to a stack growth fault. There is actually not a language construct for it
> > SIGSEGV.
> > Stack overflow for a language like C using standard implementation techniques
> > is the same
On 26 Mar 2001, James Antill wrote:
> If you want overcommit great, and I think it's a valid default
> ... but it'd be nice if I could say I don't want it for apps that
> aren't written using glib etc.
Agreed. Jonathan Morton seems to be making progress in testing
and debugging the
On Mon, 26 Mar 2001, Jonathan Morton wrote:
> I have, however, found a bug in the non-overcommit patch - it seems to
> be capable of double-freeing (and then some) - starting 4 Java VMs and
> then closing them causes VMReserved to go negative on my system.
*grin*
It's nice to see the
>> I'm currently investigating the old non-overcommit patch, which (apart from
>> needing manual applying to recent kernels) appears to be rather broken in a
>> trivial way. It prevents allocation if total reserved memory is greater
>> than the total unallocated memory. Let me say that again, a
Jonathan Morton <[EMAIL PROTECTED]> said:
> I'm currently investigating the old non-overcommit patch, which (apart from
> needing manual applying to recent kernels) appears to be rather broken in a
> trivial way. It prevents allocation if total reserved memory is greater
> than the total
Jonathan Morton [EMAIL PROTECTED] said:
I'm currently investigating the old non-overcommit patch, which (apart from
needing manual applying to recent kernels) appears to be rather broken in a
trivial way. It prevents allocation if total reserved memory is greater
than the total unallocated
I'm currently investigating the old non-overcommit patch, which (apart from
needing manual applying to recent kernels) appears to be rather broken in a
trivial way. It prevents allocation if total reserved memory is greater
than the total unallocated memory. Let me say that again, a
On Mon, 26 Mar 2001, Jonathan Morton wrote:
I have, however, found a bug in the non-overcommit patch - it seems to
be capable of double-freeing (and then some) - starting 4 Java VMs and
then closing them causes VMReserved to go negative on my system.
*grin*
It's nice to see the
On 26 Mar 2001, James Antill wrote:
If you want overcommit great, and I think it's a valid default
... but it'd be nice if I could say I don't want it for apps that
aren't written using glib etc.
Agreed. Jonathan Morton seems to be making progress in testing
and debugging the
Alan Cox wrote:
How do you return an out of memory error to a C program that is out of memory
due to a stack growth fault. There is actually not a language construct for it
SIGSEGV.
Stack overflow for a language like C using standard implementation techniques
is the same as a page
On Sun, 25 Mar 2001, Jonathan Morton wrote:
> >> My patch already fixes OOM problems caused by overgrown caches/buffers, by
> >> making sure OOM is not triggered until these buffers have been cannibalised
> >> down to freepages.high. If balancing problems still exist, then they
> >> should be
At 05:30 PM 3/25/01 +0200, you wrote:
> > Ultra reliable systems dont contain memory allocators. There are good
> reasons
> > for this but the design trade offs are rather hard to make in a real world
> > environment
>
>I esp. they run on CPU's without a stack or what?
No dynamic memory
>> My patch already fixes OOM problems caused by overgrown caches/buffers, by
>> making sure OOM is not triggered until these buffers have been cannibalised
>> down to freepages.high. If balancing problems still exist, then they
>> should be retuned with my patch (or something very like it) in
On Sun, Mar 25, 2001 at 01:32:42AM +0100, Kurt Garloff wrote:
> On Fri, Mar 23, 2001 at 05:26:22PM +, James A. Sutherland wrote:
> > If SuSE's install program needs more than a quarter Gb of RAM, you need a
> > better distro.
>
> Well, it's rpm ...
Yes. I investigated and found rpm's data
On Sat, 24 Mar 2001, Jonathan Morton wrote:
> >> While my post didn't give an exact formula, I was quite clear on the
> >>fact that
> >> the system is allowing the caches to overrun memory and cause oom problems.
> >
> >Yes. A testcase would be good. It's not happening to everybody nor is
>
>[ about non-overcommit ]
>> > Nobody feels its very important because nobody has implemented it.
>
>Enterprises use other systems because they have much better resource
>management than Linux -- adding non-overcommit wouldn't help them much.
>Desktop users, Linux newbies don't
On Sat, Mar 24, 2001 at 02:57:27AM -0300, Rik van Riel wrote:
> On Fri, 23 Mar 2001, Guest section DW wrote:
> > On Fri, Mar 23, 2001 at 11:56:23AM -0300, Rik van Riel wrote:
> > > On Fri, 23 Mar 2001, Martin Dalecki wrote:
> >
> > > > > Feel free to write better-working code.
> > > >
> > > > I
On Sat, 24 Mar 2001, Jesse Pollard wrote:
> On Fri, 23 Mar 2001, Alan Cox wrote:
[ about non-overcommit ]
> > Nobody feels its very important because nobody has implemented it.
Enterprises use other systems because they have much better resource
management than Linux -- adding
>> >start your app, wait for malloc to fail, hit enter for the other app and
>> >watch you app to be OOM killed ;)
>>
>> That would only happen if memory_overcommit was turned on, in which case my
>> modification would have zero effect anyway (the overcommit test happens
>> before my code).
>
Alan Cox wrote:
>
> > That depends what you mean by "must not". If it's your missile guidance
> > system, aircraft autopilot or life support system, the system must not run
> > out of memory in the first place. If the system breaks down badly, killing
> > init and thus panicking (hence
Kurt Garloff wrote:
> Kernel related questions IMHO are:
> (1) Why do we get into OOM?
There was a long thread about this a few months back. We get into OOM because
malloc(), calloc() etc. can allocate more memory than is actually available.
e.g. Say you have machine with 64 RAM + 64 swap =
On Fri, 23 Mar 2001, Jonathan Morton wrote:
> >The main point is letting malloc fail when the memory cannot be
> >guaranteed.
>
> If I read various things correctly, malloc() is supposed to fail as you
> would expect if /proc/sys/vm/overcommit_memory is 0. This is the case on
> my RH 6.2 box,
Stephen Satchell wrote:
>
> At 12:41 AM 3/25/01 +0100, you wrote:
> >If your box is running for example a mail server, and it appears that
> >another process is juste eating the free memory, do you really want to kill
> >the mail server, just because it's the main process and consuming more
>
Jonathan Morton wrote:
>
> >Right now my best approximation is to make the OOM test be as optimistic as
> >it is safe to be, and the vm_enough_memory() test as pessimistic as
> >sensible. Expect a test patch to appear on this list soon.
>
> ...and here it is!
>
> This fixes a number of small
Benoit Garnier wrote:
>
> Szabolcs Szakacsits wrote :
>
> > But if you start
> > to think you get the conclusion that process killing can't be avoided if
> > you want the system keep running.
>
> What's the point in keeping the OS running if the applications are silently
> killed?
>
> If your
Mike Galbraith wrote:
>
> On Sat, 24 Mar 2001, Doug Ledford wrote:
>
> [snip list of naughty behavior]
>
> > What was that you were saying about "should *never* happen"? Oh, and let's
> Get off your lazy butts and do something about it. Don't work on the
> oom-killer though.. that's only a
Doug Ledford wrote:
>
> Horst von Brand wrote:
> >
> > "Christian Bodmer" <[EMAIL PROTECTED]> said:
> >
> > > I can't say I understand the whole MM system, however the random killing
> > > of processes seems like a rather unfortunate solution to the problem. If
> > > someone has a spare minute,
Doug Ledford wrote:
Horst von Brand wrote:
"Christian Bodmer" [EMAIL PROTECTED] said:
I can't say I understand the whole MM system, however the random killing
of processes seems like a rather unfortunate solution to the problem. If
someone has a spare minute, maybe they could
Mike Galbraith wrote:
On Sat, 24 Mar 2001, Doug Ledford wrote:
[snip list of naughty behavior]
What was that you were saying about "should *never* happen"? Oh, and let's
Get off your lazy butts and do something about it. Don't work on the
oom-killer though.. that's only a symptom.
Benoit Garnier wrote:
Szabolcs Szakacsits wrote :
But if you start
to think you get the conclusion that process killing can't be avoided if
you want the system keep running.
What's the point in keeping the OS running if the applications are silently
killed?
If your box is
Jonathan Morton wrote:
Right now my best approximation is to make the OOM test be as optimistic as
it is safe to be, and the vm_enough_memory() test as pessimistic as
sensible. Expect a test patch to appear on this list soon.
...and here it is!
This fixes a number of small but linked
Stephen Satchell wrote:
At 12:41 AM 3/25/01 +0100, you wrote:
If your box is running for example a mail server, and it appears that
another process is juste eating the free memory, do you really want to kill
the mail server, just because it's the main process and consuming more
memory and
On Fri, 23 Mar 2001, Jonathan Morton wrote:
The main point is letting malloc fail when the memory cannot be
guaranteed.
If I read various things correctly, malloc() is supposed to fail as you
would expect if /proc/sys/vm/overcommit_memory is 0. This is the case on
my RH 6.2 box, dunno
Kurt Garloff wrote:
Kernel related questions IMHO are:
(1) Why do we get into OOM?
There was a long thread about this a few months back. We get into OOM because
malloc(), calloc() etc. can allocate more memory than is actually available.
e.g. Say you have machine with 64 RAM + 64 swap = 128
Alan Cox wrote:
That depends what you mean by "must not". If it's your missile guidance
system, aircraft autopilot or life support system, the system must not run
out of memory in the first place. If the system breaks down badly, killing
init and thus panicking (hence rebooting, if the
start your app, wait for malloc to fail, hit enter for the other app and
watch you app to be OOM killed ;)
That would only happen if memory_overcommit was turned on, in which case my
modification would have zero effect anyway (the overcommit test happens
before my code).
Thanks for
On Sat, 24 Mar 2001, Jesse Pollard wrote:
On Fri, 23 Mar 2001, Alan Cox wrote:
[ about non-overcommit ]
Nobody feels its very important because nobody has implemented it.
Enterprises use other systems because they have much better resource
management than Linux -- adding
On Sat, Mar 24, 2001 at 02:57:27AM -0300, Rik van Riel wrote:
On Fri, 23 Mar 2001, Guest section DW wrote:
On Fri, Mar 23, 2001 at 11:56:23AM -0300, Rik van Riel wrote:
On Fri, 23 Mar 2001, Martin Dalecki wrote:
Feel free to write better-working code.
I don't get paid for
[ about non-overcommit ]
Nobody feels its very important because nobody has implemented it.
Enterprises use other systems because they have much better resource
management than Linux -- adding non-overcommit wouldn't help them much.
Desktop users, Linux newbies don't understand
On Sat, 24 Mar 2001, Jonathan Morton wrote:
While my post didn't give an exact formula, I was quite clear on the
fact that
the system is allowing the caches to overrun memory and cause oom problems.
Yes. A testcase would be good. It's not happening to everybody nor is
it happening
On Sun, Mar 25, 2001 at 01:32:42AM +0100, Kurt Garloff wrote:
On Fri, Mar 23, 2001 at 05:26:22PM +, James A. Sutherland wrote:
If SuSE's install program needs more than a quarter Gb of RAM, you need a
better distro.
Well, it's rpm ...
Yes. I investigated and found rpm's data base
My patch already fixes OOM problems caused by overgrown caches/buffers, by
making sure OOM is not triggered until these buffers have been cannibalised
down to freepages.high. If balancing problems still exist, then they
should be retuned with my patch (or something very like it) in hand, to
At 05:30 PM 3/25/01 +0200, you wrote:
Ultra reliable systems dont contain memory allocators. There are good
reasons
for this but the design trade offs are rather hard to make in a real world
environment
I esp. they run on CPU's without a stack or what?
No dynamic memory allocation AT
On Sun, 25 Mar 2001, Jonathan Morton wrote:
My patch already fixes OOM problems caused by overgrown caches/buffers, by
making sure OOM is not triggered until these buffers have been cannibalised
down to freepages.high. If balancing problems still exist, then they
should be retuned with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Mar 24, 2001 at 09:45:01PM -0800, Stephen Satchell wrote:
> If you have a mission-critical application running on your box, add it to
> the inittab file with the RESPAWN attribute. That way, OOM killer kills
> it, init notices it, and init
At 12:41 AM 3/25/01 +0100, you wrote:
>If your box is running for example a mail server, and it appears that
>another process is juste eating the free memory, do you really want to kill
>the mail server, just because it's the main process and consuming more
>memory and CPU than others?
>
>Well,
On Fri, Mar 23, 2001 at 05:26:22PM +, James A. Sutherland wrote:
> If SuSE's install program needs more than a quarter Gb of RAM, you need a
> better distro.
Well, it's rpm ...
I guess the Debian packager is more friendly.
But if you choose to install a huge number of packages, the job to do
>> While my post didn't give an exact formula, I was quite clear on the
>>fact that
>> the system is allowing the caches to overrun memory and cause oom problems.
>
>Yes. A testcase would be good. It's not happening to everybody nor is
>it happening under all loads. (if it were, it'd be long
>> free = atomic_read(_pages);
>> free += atomic_read(_cache_size);
>> free += nr_free_pages();
>> - free += nr_swap_pages;
>
>> + /* Since getting swap info is expensive, see if our allocation
>>can happen in physical RAM */
>
>Actually, getting swap info is
Szabolcs Szakacsits wrote :
> But if you start
> to think you get the conclusion that process killing can't be avoided if
> you want the system keep running.
What's the point in keeping the OS running if the applications are silently
killed?
If your box is running for example a mail server,
On Sat, 24 Mar 2001, Doug Ledford wrote:
> Mike Galbraith wrote:
> >
> > General thread comment:
> > To those who are griping, and obviously rightfully so, Rik has twice
> > stated on this list that he could use some help with VM auto-balancing.
> > The responses (visible on this list at least)
On Sat, 24 Mar 2001, Jonathan Morton wrote:
> free = atomic_read(_pages);
> free += atomic_read(_cache_size);
> free += nr_free_pages();
> - free += nr_swap_pages;
> + /* Since getting swap info is expensive, see if our allocation can happen in
>physical RAM
>Right now my best approximation is to make the OOM test be as optimistic as
>it is safe to be, and the vm_enough_memory() test as pessimistic as
>sensible. Expect a test patch to appear on this list soon.
...and here it is!
This fixes a number of small but linked problems:
- malloc() never
On Fri, 23 Mar 2001, Paul Jakma wrote:
>On Fri, 23 Mar 2001, Guest section DW wrote:
>
>> But yes, I am complaining because Linux by default is unreliable.
>
>no, your distribution is unreliable by default.
>
>> I strongly prefer a system that is reliable by default,
>> and I'll leave it to
>While my post didn't give an exact formula, I was quite clear on the fact that
>the system is allowing the caches to overrun memory and cause oom problems.
>I'm more than happy to test patches, and I would even be willing to suggest
>some algorithms that might help, but I don't know where to
Mike Galbraith wrote:
>
> On Sat, 24 Mar 2001, Doug Ledford wrote:
> > To those people that would suggest I send in code I only have this to say.
> > Fine, I'll send in a patch to fix this bug. It will make the oom killer call
> > the cache reclaim functions and never kill anything. That would
On Fri, 23 Mar 2001, Alan Cox wrote:
>> infinite storage. After all, earlier Unix flavours did not need
>> an OOM killer either, and my editor was not killed under Unix V6
>> on 64k when I started some other process.
>
>You were lucky. Its quite possible for V6 to kill processes when you run out
On Sat, 24 Mar 2001, Jonathan Morton wrote:
> >General thread comment:
> >To those who are griping, and obviously rightfully so, Rik has twice
> >stated on this list that he could use some help with VM auto-balancing.
> >The responses (visible on this list at least) was rather underwhelming.
>
>I thought of some things which could break it, which I want to try and deal
>with before releasing a patch. Specifically, I want to make freepages.min
>sacrosanct, so that malloc() *never* tries to use it. This should be
>fairly easy to implement - simply subtract freepages.min from the
On Fri, 23 Mar 2001, Stephen E. Clark wrote:
> Alan Cox wrote:
> >
> > > You don't beleve me if I tell you: DOS extender and JVM (Java Virtual
> > > Machine)
> >
> > The JVM doesnt actually. The JVM will itself spontaenously explode in real
> > life when out of memory. Maybe the JVM on a DOS
At 6:58 am + 24/3/2001, Rik van Riel wrote:
>On Sat, 24 Mar 2001, Jonathan Morton wrote:
>
>> Hmm... "if ( freemem < (size_of_mallocing_process / 20) )
>>fail_to_allocate;"
>>
>> Seems like a reasonable soft limit - processes which have already got
>> lots of RAM can probably stand not to
>General thread comment:
>To those who are griping, and obviously rightfully so, Rik has twice
>stated on this list that he could use some help with VM auto-balancing.
>The responses (visible on this list at least) was rather underwhelming.
>I noted no public exchange of ideas.. nada in fact.
>
From [EMAIL PROTECTED] Sat Mar 24 03:00:17 2001
> No, ulimit does not work. (But it helps a little.)
no, not perfect, i very much agree. but in daily usage it reduces
chance of OOM to close to 0.
No. How would you use it? Compute individual limits for
each process? One
On Sat, 24 Mar 2001, Doug Ledford wrote:
[snip list of naughty behavior]
> What was that you were saying about "should *never* happen"? Oh, and let's
> not overlook the fact that it killed off mostly system daemons to start off
> with while leaving the real culprits alone. Once it did get
On Sat, 24 Mar 2001, Doug Ledford wrote:
[snip list of naughty behavior]
What was that you were saying about "should *never* happen"? Oh, and let's
not overlook the fact that it killed off mostly system daemons to start off
with while leaving the real culprits alone. Once it did get around
From [EMAIL PROTECTED] Sat Mar 24 03:00:17 2001
No, ulimit does not work. (But it helps a little.)
no, not perfect, i very much agree. but in daily usage it reduces
chance of OOM to close to 0.
No. How would you use it? Compute individual limits for
each process? One typically
General thread comment:
To those who are griping, and obviously rightfully so, Rik has twice
stated on this list that he could use some help with VM auto-balancing.
The responses (visible on this list at least) was rather underwhelming.
I noted no public exchange of ideas.. nada in fact.
Get off
At 6:58 am + 24/3/2001, Rik van Riel wrote:
On Sat, 24 Mar 2001, Jonathan Morton wrote:
Hmm... "if ( freemem (size_of_mallocing_process / 20) )
fail_to_allocate;"
Seems like a reasonable soft limit - processes which have already got
lots of RAM can probably stand not to have that
On Fri, 23 Mar 2001, Stephen E. Clark wrote:
Alan Cox wrote:
You don't beleve me if I tell you: DOS extender and JVM (Java Virtual
Machine)
The JVM doesnt actually. The JVM will itself spontaenously explode in real
life when out of memory. Maybe the JVM on a DOS extender 8)
I thought of some things which could break it, which I want to try and deal
with before releasing a patch. Specifically, I want to make freepages.min
sacrosanct, so that malloc() *never* tries to use it. This should be
fairly easy to implement - simply subtract freepages.min from the freemem
On Sat, 24 Mar 2001, Jonathan Morton wrote:
General thread comment:
To those who are griping, and obviously rightfully so, Rik has twice
stated on this list that he could use some help with VM auto-balancing.
The responses (visible on this list at least) was rather underwhelming.
I noted no
On Fri, 23 Mar 2001, Alan Cox wrote:
infinite storage. After all, earlier Unix flavours did not need
an OOM killer either, and my editor was not killed under Unix V6
on 64k when I started some other process.
You were lucky. Its quite possible for V6 to kill processes when you run out
of swap
Mike Galbraith wrote:
On Sat, 24 Mar 2001, Doug Ledford wrote:
To those people that would suggest I send in code I only have this to say.
Fine, I'll send in a patch to fix this bug. It will make the oom killer call
the cache reclaim functions and never kill anything. That would at
While my post didn't give an exact formula, I was quite clear on the fact that
the system is allowing the caches to overrun memory and cause oom problems.
I'm more than happy to test patches, and I would even be willing to suggest
some algorithms that might help, but I don't know where to stick
On Sat, 24 Mar 2001, Jonathan Morton wrote:
free = atomic_read(buffermem_pages);
free += atomic_read(page_cache_size);
free += nr_free_pages();
- free += nr_swap_pages;
+ /* Since getting swap info is expensive, see if our allocation can happen in
On Sat, 24 Mar 2001, Doug Ledford wrote:
Mike Galbraith wrote:
General thread comment:
To those who are griping, and obviously rightfully so, Rik has twice
stated on this list that he could use some help with VM auto-balancing.
The responses (visible on this list at least) was rather
free = atomic_read(buffermem_pages);
free += atomic_read(page_cache_size);
free += nr_free_pages();
- free += nr_swap_pages;
+ /* Since getting swap info is expensive, see if our allocation
can happen in physical RAM */
Actually, getting swap info is as
Szabolcs Szakacsits wrote :
But if you start
to think you get the conclusion that process killing can't be avoided if
you want the system keep running.
What's the point in keeping the OS running if the applications are silently
killed?
If your box is running for example a mail server, and
While my post didn't give an exact formula, I was quite clear on the
fact that
the system is allowing the caches to overrun memory and cause oom problems.
Yes. A testcase would be good. It's not happening to everybody nor is
it happening under all loads. (if it were, it'd be long dead)
On Fri, Mar 23, 2001 at 05:26:22PM +, James A. Sutherland wrote:
If SuSE's install program needs more than a quarter Gb of RAM, you need a
better distro.
Well, it's rpm ...
I guess the Debian packager is more friendly.
But if you choose to install a huge number of packages, the job to do
At 12:41 AM 3/25/01 +0100, you wrote:
If your box is running for example a mail server, and it appears that
another process is juste eating the free memory, do you really want to kill
the mail server, just because it's the main process and consuming more
memory and CPU than others?
Well, fine,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Mar 24, 2001 at 09:45:01PM -0800, Stephen Satchell wrote:
If you have a mission-critical application running on your box, add it to
the inittab file with the RESPAWN attribute. That way, OOM killer kills
it, init notices it, and init
"James A. Sutherland" wrote:
> On Thu, 22 Mar 2001, Guest section DW wrote:
> > (I think 2.4.0.)
> >
> > Clearly, Linux cannot be reliable if any process can be killed
> > at any moment.
>
> What on earth did you expect to happen when the process exceeded the
> machine's capabilities? Using more
Horst von Brand wrote:
>
> "Christian Bodmer" <[EMAIL PROTECTED]> said:
>
> > I can't say I understand the whole MM system, however the random killing
> > of processes seems like a rather unfortunate solution to the problem. If
> > someone has a spare minute, maybe they could explain to me why
On Sat, 24 Mar 2001, Jonathan Morton wrote:
> Hmm... "if ( freemem < (size_of_mallocing_process / 20) ) fail_to_allocate;"
>
> Seems like a reasonable soft limit - processes which have already got
> lots of RAM can probably stand not to have that little bit more and
> can be curbed more
:: Your ideas sound really good, would you have the time to implement
:: them for 2.4 ?
2.4 or 2.5?
-- Juha
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 23 Mar 2001, Guest section DW wrote:
> On Fri, Mar 23, 2001 at 11:56:23AM -0300, Rik van Riel wrote:
> > On Fri, 23 Mar 2001, Martin Dalecki wrote:
>
> > > > Feel free to write better-working code.
> > >
> > > I don't get paid for it and I'm not idling through my days...
> >
> >
>
On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
> When I ported your OOM killer to 2.2.x and integrated it into the
> 'reserved root memory' [*] patch, during intensive testing I found two
> cases when init was killed. It happened on low-end machines and when
> OOM killer wasn't triggered so
On Fri, 23 Mar 2001, george anzinger wrote:
> What happens if you just make swap VERY large? Does the system thrash
> it self to a virtual standstill?
It does. I need to implement load control code (so we suspend
processes in turn to keep the load low enough so we can avoid
thrashing).
> Is
,--- Forwarded message (begin)
Subject: Re: [PATCH] Prevent OOM from killing init
From: Jonathan Morton <[EMAIL PROTECTED]>
Date: Fri, 23 Mar 2001 20:45:43 -0500
>Hmm... "if ( freemem < (size_of_mallocing_process / 20) ) fail_to_allocate;"
Not sure t
Hi together,
seems like a hot discussion going on, but I couldn't resist and would like to
throw in my $0.02.
Besides misunderstandings and general displeasure, some very interesting
facts have shown up in the discussion (oh, yeah), which I'd like to know more
about, and just extend them with a
On Sat, 24 Mar 2001, Szabolcs Szakacsits wrote:
> Nonsense hodgepodge. See and/or mesaure the impact. I sent numbers in my
> former email. You also missed non-overcommit must be _optional_ [i.e.
> you wouldn't be forced to use it ;)]. Yes, there are users and
> enterprises who require it and
On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
> No, ulimit does not work. (But it helps a little.)
no, not perfect, i very much agree. but in daily usage it reduces
chance of OOM to close to 0.
> No, /proc/sys/vm/overcommit_memory does not work.
that's because it disables the very rough
>Hmm... "if ( freemem < (size_of_mallocing_process / 20) ) fail_to_allocate;"
>
>Seems like a reasonable soft limit - processes which have already got lots
>of RAM can probably stand not to have that little bit more and can be
>curbed more quickly. Processes with less probably don't deserve to
> It was actually worse than that. Grab your copy of "Lions", and check lines
> 4375-4377 in function xswap(). A failure to allocate space in the swapmap
> caused a panic. Same problem in xalloc().
[no Lions nearby; somewhere I still have the printout but am
too lazy to search; I also have the
On Fri, Mar 23, 2001 at 06:38:37PM +, Alan Cox wrote:
> > infinite storage. After all, earlier Unix flavours did not need
> > an OOM killer either, and my editor was not killed under Unix V6
> > on 64k when I started some other process.
>
> You were lucky. Its quite possible for V6 to kill
1 - 100 of 288 matches
Mail list logo
