[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.020 / U:10.120 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site