[lkml]   [2000]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Avoiding OOM on overcommit...?
    Richard Gooch wrote:
    > Because it's different (read harder)? I still haven't seen a
    > description of how we handle stack exhaustion properly. All we can do
    > there is kill the offending process.
    Naw....we have lots of options. The first and best 1) A gram of
    prevention is worth a kilogram of cure. If the developer or user knows that
    a given program uses alot of stack space, then an option in 'ld' to specify
    size of stack to commit, or 2) User says "runprog -stacksize=1M <programname>"
    or some such option -- and 1M of stack space is committed/reserved before
    when loading the program. 3) We use a signal -- I sorta like overuse of
    SIGSTKFLT, but there may be reasons not to use it. If in default, program
    dies as from a SEGV, and 4) if ignored, program is put to sleep waiting on
    free pages.

    Ok, maybe that wasn't lots, but it was at least 4! :-)

    Not to sound repetitious, but why is lack of memory (a resource as
    David puts it) so different from #processes, #open files/system /process,
    out of diskspace on a write call, unable to acquire a 'lock' resource...

    Those just return error's or 'sleep'. Why should we come up with
    a new paradigm for memory?


    Linda A Walsh | Trust Technology, Core Linux, SGI | Voice: (650) 933-5338

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