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, al
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 in
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 a
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 non-overcom
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 non-overco
>> 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 unalloca
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 re
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 allocati
>> 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 ha
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 ba
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
>[ 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 understan
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 non-over
>> >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).
>
>Tha
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,
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
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, d
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
> >me
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 b
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 sy
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, m
-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, fi
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 de
>> 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
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
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) w
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
>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 re
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 others
>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 stic
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
>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 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 hav
>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.
>
>G
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
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 arou
"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 r
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 quickly
:: 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
P
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 init
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 t
,--- 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 this
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 woul
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 resourc
>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 d
> 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 t
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 pr
On Fri, 23 Mar 2001, Tim Wright wrote:
> Netscape 4 has some very nasty habits like suddenly consuming ~80MB of memory.
> Disabling java support seems to eradicate most occurences of this particularly
> obnoxious behaviour. Under these circumstances, the OOM killer is doing exactly
> the right th
>[to various people]
>
>No, ulimit does not work. (But it helps a little.)
>No, /proc/sys/vm/overcommit_memory does not work.
Entirely correct. ulimit certainly makes it much harder for a single
runaway process to take down important parts of the system - now why
doesn't $(MAJOR_DISTRO_VENDOR) s
On Fri, Mar 23, 2001 at 05:26:22PM +, James A. Sutherland wrote:
> > 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 than all the resources fails. T
Netscape 4 has some very nasty habits like suddenly consuming ~80MB of memory.
Disabling java support seems to eradicate most occurences of this particularly
obnoxious behaviour. Under these circumstances, the OOM killer is doing exactly
the right thing i.e. killing a runaway app.
Tim
On Fri, Ma
Guest section DW <[EMAIL PROTECTED]> writes:
> On Fri, Mar 23, 2001 at 07:50:25AM -0700, Eric W. Biederman wrote:
>
> > > Mar 23 11:48:49 mette kernel: Out of Memory: Killed process 2019 (emacs).
> > > Mar 23 11:48:49 mette kernel: Out of Memory: Killed process 1407 (emacs).
> > > Mar 23 11:48:5
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)
>
> -
> To unsubscribe from this list: send the l
[EMAIL PROTECTED] wrote:
>
> [to various people]
>
> No, ulimit does not work. (But it helps a little.)
> No, /proc/sys/vm/overcommit_memory does not work.
>
> [to Alan]
>
> > Nobody feels its very important because nobody has implemented it.
>
> Yes, that is the right response.
> What can on
Jonathan Morton <[EMAIL PROTECTED]> writes:
> >It would make much sense to make the oom killer
> >leave not just root processes alone but processes belonging to a UID
> >lower
> >then a certain value as well (500). This would be:
> >
> >1. Easly managable by the admin. Just let oracle/www and ana
[to various people]
No, ulimit does not work. (But it helps a little.)
No, /proc/sys/vm/overcommit_memory does not work.
[to Alan]
> Nobody feels its very important because nobody has implemented it.
Yes, that is the right response.
What can one say? One can only do.
Andries
-
To unsubscribe
On Fri, 23 Mar 2001, Alan Cox wrote:
> > > and rely on it. You might find you need a few Gbytes of swap just to
> > > boot
> > Seems a bit exaggeration ;) Here are numbers,
> NetBSD is if I remember rightly still using a.out library styles.
No, it uses ELF today, moreover the numbers were from S
> > and rely on it. You might find you need a few Gbytes of swap just to
> > boot
>
> Seems a bit exaggeration ;) Here are numbers,
NetBSD is if I remember rightly still using a.out library styles.
> 6-50% more VM and the performance hit also isn't so bad as it's thought
> (Eduardo Horvath sen
> 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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Fri, 23 Mar 2001, Paul Jakma wrote:
> On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
> > About the "use resource limits!". Yes, this is one solution. The
> > *expensive* solution (admin time, worse resource utilization, etc).
Thanks for cutting out relevant parts that said how to increase us
What happens if you just make swap VERY large? Does the system thrash
it self to a virtual standstill? Is this a possible answer? Supposedly
you could then sneak in and blow away the bad guys manually ...
George
Paul Jakma wrote:
>
> On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
>
> > Abo
>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 about yours. I can write a simple test program whic
SodaPop wrote:
>
> On Fri, 23 Mar 2001, Martin Dalecki wrote:
>
> > SodaPop wrote:
> > >
> > > Rik, is there any way we could get a /proc entry for this, so that one
> > > could do something like:
> >
> > I will respond; NO there is no way for security reasons this is not a
> > good idea.
> >
>
On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
> About the "use resource limits!". Yes, this is one solution. The
> *expensive* solution (admin time, worse resource utilization, etc).
traditional user limits have worse resource utilisation? think what
kind of utilisation a guaranteed allocation
On Fri, 23 Mar 2001, Rik van Riel wrote:
> Well, in that case you'll have to live with the current OOM
> killer. Martin wrote down a pretty detailed description of
> what's wrong with my algorithm, if it really bothers him he
> should be able to come up with something better.
>
> Personally, I t
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 others to run it in an unreliable mode.
currently, s
On Fri, 23 Mar 2001, Martin Dalecki wrote:
> SodaPop wrote:
> >
> > Rik, is there any way we could get a /proc entry for this, so that one
> > could do something like:
>
> I will respond; NO there is no way for security reasons this is not a
> good idea.
>
> > cat /proc/oom-kill-scores | sort +3
On Friday, 23 March 2001, at 12:28:15 +0100,
Guest section DW wrote:
> [...]
> To a murderer: "Why did you kill that old lady?"
> Reply: "I won't defend that deed, but who else should I have killed?"
>
No comments.
> Andries - getting more and more unhappy with OOM
>
> Mar 23 11:48:49 mette ke
>It would make much sense to make the oom killer
>leave not just root processes alone but processes belonging to a UID
>lower
>then a certain value as well (500). This would be:
>
>1. Easly managable by the admin. Just let oracle/www and analogous users
> have a UID lower then let's say 500.
Th
On Thu, 22 Mar 2001, Alan Cox wrote:
> I'd like to have it there as an option. As to the default - You
> would have to see how much applications assume they can overcommit
> and rely on it. You might find you need a few Gbytes of swap just to
> boot
Seems a bit exaggeration ;) Here are numbers,
On Thu, 22 Mar 2001, Guest section DW wrote:
> Presently however, a flawless program can be killed.
> That is what makes Linux unreliable.
Your advocation is "save the application, crash the OS!". But you can't
be blamed because everybody's first reaction is this :) But if you start
to think you
At 10:28 AM 3/23/01 +0100, you wrote:
>Ehrm, I would like to re-state that it still would be nice if
>some mechanism got introduced which enables one to set certain
>processes to "cannot be killed".
>For example: I would hate it it the UPS monitoring daemon got
>killed for obvious reasons :o)
Hey
The only thing out of that I don't belive is that it's a useable Operating
System. I like your solution though. Thanks for actually comeing up with
a useable solution instead of mindlessly ranting.
Nick
On Fri, 23 Mar 2001, Martin Dalecki wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Plea
On Thu, 22 Mar 2001, Alan Cox wrote:
> One of the things that we badly need to resurrect for 2.5 is the
> beancounter work which would let you reasonably do things like
> guaranteed Oracle a certain amount of the machine, or restrict all
> the untrusted users to a total of 200Mb hard limit betwe
>> Rik, is there any way we could get a /proc entry for this, so that one
>> could do something like:
>
>I will respond; NO there is no way for security reasons this is not a
>good idea.
Just out of interest, what information does the OOM score expose that isn't
already available to Joe Random Un
[EMAIL PROTECTED] wrote:
>
> Please point me to an Operating System that runs on any commonly available
> platform and fits your requirements.
> Nick
You don't beleve me if I tell you: DOS extender and JVM (Java Virtual
Machine)
-
To unsubscribe from this list: send the line "unsubscribe
I have a constructive proposal:
It would make much sense to make the oom killer
leave not just root processes alone but processes belonging to a UID
lower
then a certain value as well (500). This would be:
1. Easly managable by the admin. Just let oracle/www and analogous users
have a UID low
SodaPop wrote:
>
> Rik, is there any way we could get a /proc entry for this, so that one
> could do something like:
I will respond; NO there is no way for security reasons this is not a
good idea.
> cat /proc/oom-kill-scores | sort +3
-
To unsubscribe from this list: send the line "unsubscrib
Please point me to an Operating System that runs on any commonly available
platform and fits your requirements.
Nick
On Fri, 23 Mar 2001 [EMAIL PROTECTED] wrote:
> On Fri, Mar 23, 2001 at 05:04:07PM +, Alan Cox wrote:
> > > This is just an escape route in case everything else has fai
> 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
> The old Unix guarantee that a pr
On Fri, Mar 23, 2001 at 05:04:07PM +, Alan Cox wrote:
> > This is just an escape route in case everything else has failed.
> >
> > Linux is unreliable.
> > That is bad.
>
> Since your definition of reliability is a mathematical abstraction requiring
> infinite storage why don't you start by in
> 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 system is set up th
On Fri, Mar 23, 2001 at 07:50:25AM -0700, Eric W. Biederman wrote:
> > Mar 23 11:48:49 mette kernel: Out of Memory: Killed process 2019 (emacs).
> > Mar 23 11:48:49 mette kernel: Out of Memory: Killed process 1407 (emacs).
> > Mar 23 11:48:50 mette kernel: Out of Memory: Killed process 1495 (emac
On Thu, 22 Mar 2001, Guest section DW wrote:
> On Wed, Mar 21, 2001 at 08:48:54PM -0300, Rik van Riel wrote:
> > On Wed, 21 Mar 2001, Patrick O'Rourke wrote:
>
> > > Since the system will panic if the init process is chosen by
> > > the OOM killer, the following patch prevents select_bad_process()
On Wed, 21 Mar 2001, Rik van Riel wrote:
> One question ... has the OOM killer ever selected init on
> anybody's system ?
Hi Rik,
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.
> This is just an escape route in case everything else has failed.
>
> Linux is unreliable.
> That is bad.
Since your definition of reliability is a mathematical abstraction requiring
infinite storage why don't you start by inventing infinitely large SDRAM
chips, then get back to us ?
-
To unsu
Rik, is there any way we could get a /proc entry for this, so that one
could do something like:
cat /proc/oom-kill-scores | sort +3
to get a process list (similar to ps) with a field for the current oom
scores? It would likely be very useful to be able to dump the current
scores and see what wi
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...
>
>
No lies please.
Andries
-
To unsubscribe from this list: send t
On Fri, Mar 23, 2001 at 12:24:03PM -0400, Horst von Brand wrote:
> Can we please remember that OOM is *not* in any way a "normal system state"
> that has to be handled in a civilized, orderly way? This is just an escape
> route in case everything else has failed.
Can we please remember that a Bl
1 - 100 of 149 matches
Mail list logo
