[lkml]   [2000]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Virtual vs. physical swap & shared memory forks (clone)
    On Sat, 25 Mar 2000, Richard Gooch wrote:
    >Linda Walsh writes:
    >> > Removing overcommit might make malloc() return null, but that's only one
    >> > of a host of ways to allocate memory. The other methods don't have a
    >> > return value. So arguing that "overcommit is bad, because it breaks the
    >> > malloc() return value" is pointless.
    >> What other methods? calloc - ENOMEM, open <object>, ENOMEM, fork:
    >> ENOMEM. Etc. All what you would expect if there was NOMEM.
    >Stack "allocation". No error code available.

    This is the one place where a stack warning signal would be usefull - when
    the last page of stack is entered, a signal can be sent, and handled.

    This has been done on other unix systems, and can be completely hidden from
    the user by installing the signal handler before calling the function main().

    To reduce the number of faults generated, I would suggest
    a) an initial allocation (determined by sysadmin) to be large enough to cover
    50-75% of the programs. This would allow the standard utilities to never
    see a fault. If the sysadm preferred, the size could be trimmed.
    b) when the stack is extended (amount determined by sysadmin) it is extended by
    enough to increase the time to the next page fault.

    This might be done by modifing (I know, this might break something) brk to
    have two parameters - a segment end, and a stack/heap flag. If it knew the
    heap is being extended, then the operation is the same as current.
    If the flag is stack, then it extends the user stack.

    In either case, if the extension fails, then the user process knows it
    before a catastrophic abort occurs.

    In the non-overcommited operation the process knows it is reaching the
    users virtual limit.

    Jesse I Pollard, II

    Any opinions expressed are solely my own.

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