Messages in this thread | | | Date | Sat, 30 Jan 2010 13:33:49 +0100 | From | Vedran Furač <> | Subject | Re: [PATCH v3] oom-kill: add lowmem usage aware oom kill handling |
| |
Alan Cox wrote:
>> off by default. Problem is that it breaks java and some other stuff that >> allocates much more memory than it needs. Very quickly Committed_AS hits >> CommitLimit and one cannot allocate any more while there is plenty of >> memory still unused. > > So how about you go and have a complain at the people who are causing > your problem, rather than the kernel.
That would pass completely unnoticed and ignored as long as overcommit is enabled by default.
>>> theoretical limit, but you generally need more swap (it's one of the >>> reasons why things like BSD historically have a '3 * memory' rule). >> Say I have 8GB of memory and there's always some free, why would I need >> swap? > > So that all the applications that allocate tons of address space and > don't use it can swap when you hit that corner case, and as a result you > don't need to go OOM. You should only get an OOM when you run out of > memory + swap.
Yes, but unfortunately using swap makes machine crawl with huge disk IO every time you access some application you haven't been using for a few hours. So recently more and more people are disabling it completely with positive experience.
>>> So sounds to me like a problem between the keyboard and screen (coupled >> Unfortunately it is not. Give me ssh access to your computer (leave >> overcommit on) and I'll kill your X with anything running on it. > > If you have overcommit on then you can cause stuff to get killed. Thats > what the option enables.
s/stuff/wrong stuff/
> It's really very simple: overcommit off you must have enough RAM and swap > to hold all allocations requested. Overcommit on - you don't need this > but if you do use more than is available on the system something has to > go. > > It's kind of like banking overcommit off is proper banking, overcommit > on is modern western banking.
Hehe, yes and you know the consequences.
If you look at malloc(3) you would see this:
"This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug."
So, if you don't want to change the OOM algorithm why not fixing this bug then? And after that change the proc(5) manpage entry for /proc/sys/vm/overcommit_memory into something like:
0: heuristic overcommit (enable this if you have memory problems with some buggy software) 1: always overcommit, never check 2: always check, never overcommit (this is the default)
Regards, Vedran
-- http://vedranf.net | a8e7a7783ca0d460fee090cc584adc12 begin:vcard fn;quoted-printable:Vedran Fura=C4=8D n;quoted-printable:Fura=C4=8D;Vedran adr:;;;;;;Croatia email;internet:vedran.furac@gmail.com x-mozilla-html:FALSE url:http://vedranf.net version:2.1 end:vcard
| |