Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: Avoiding OOM on overcommit...? | Date | Wed, 29 Mar 2000 19:48:02 +0200 (MET DST) |
| |
"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.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |