[lkml]   [2000]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Avoiding OOM on overcommit...?
"A month of sundays ago James Sutherland wrote:"
> On Sun, 26 Mar 2000 17:50:37 +0200 (MET DST), you wrote:
> >And I arrived later too. But while we're on the subject of swap space,
> >doesn't "reserve me 8MB of disk-based swap as backing for my stack" cure
> >everyones OOM blues? I propose that that's a fair use for swap nowadays.
> >I don't _actually_ want to use swap myself, and having it there only
> >as the "gold-standard" at the back of the IOU seems the best use.
> On the contrary - reserving an extra 8Mb of swap per process would

I replied to your privately already. I don't know how you get this
idea. It's easy to show that no process can go OOM on stack if every
process has backing reserved to take its stack pages when they have
to be taken out of ram for whatever reason.

> CAUSE further OOM problems. You would still run OOM, it would just

No. Try again. If that's the best you can do, your whole argument till
now has been specious.

> happen sooner than it otherwise would.

Perhaps you are confusing "not being able to start more processes" with
"an existing process getting an unexpected signal due to an
unobservable system condition not of its making or ever reported to
it". The latter is OOM. It can never happen when no process can start
unless there is swap space available to take its max stack (which
guarantees that stack memory is never overcommitted), AND every access
to malloc is wrappped as gnumalloc does it (which guarantess that heap
memory can never be overcommitted).

I posted a simple bsd-like accounting scheme + kernel policy that
guarantees the above and makes provision for both "secure" and
"non-secure" types of processes. You can do better than it, but it at
least works.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.062 / U:4.180 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site