[9fans] plan 9 overcommits memory? - Plan9

This is a discussion on [9fans] plan 9 overcommits memory? - Plan9 ; i was trying to tickle a kernel panic, but instead i think i found a bug. this program was run on a machine with 1800 MB user space available. (3552/464510 user) #include #include enum{ Big = 1024*1024*1790, }; void main(void) ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: [9fans] plan 9 overcommits memory?

  1. [9fans] plan 9 overcommits memory?

    i was trying to tickle a kernel panic, but instead
    i think i found a bug. this program was run on
    a machine with 1800 MB user space available.
    (3552/464510 user)

    #include
    #include

    enum{
    Big = 1024*1024*1790,
    };

    void
    main(void)
    {
    char *p;
    ulong i;

    p = malloc(Big);
    if(p == 0)
    sysfatal("malloc: %r");
    memset(p, 0, Big);
    exits("");
    }

    the result was

    ladd# out of physical memory; no swap configured
    364: 8.out killed: out of memory

    this means that the malloc *succeeded* it wasn't until i forced
    the pagefault with the memset that i ran out of memory. what's
    going on here?

    - erik

  2. Re: [9fans] plan 9 overcommits memory?

    > this means that the malloc *succeeded* it wasn't until i forced
    > the pagefault with the memset that i ran out of memory. what's
    > going on here?


    you know what's going on here. read the subject you wrote.

    the problem is not really as easy as it might seem at first.
    malloc just moves the brk, but the backing pages don't get
    allocated until the pages are accessed (during memset).

    you could argue for some kind of accounting that would
    ensure pages were available, but this could only be
    terribly pessimistic, especially in the case of stacks
    and fork.

    russ


  3. Re: [9fans] plan 9 overcommits memory?

    > the problem is not really as easy as it might seem at first.
    > malloc just moves the brk, but the backing pages don't get
    > allocated until the pages are accessed (during memset).
    >


    i'm just suprised that plan 9 overcommits. this makes
    this code nonsensical from user space

    if((p = malloc(Size)) == 0)
    /* malloc recovery code */
    /* why bother? the kernel could be lying to us anyway. */

    also, by default plan 9 assumes that there are 16 MB of memory
    more than actually exist. i would think with today's large memories
    typically, one would want to assume the worst and underestimate
    the amount of memory required so malloc would fail rather than
    getting a page fault later.

    > you could argue for some kind of accounting that would
    > ensure pages were available, but this could only be
    > terribly pessimistic, especially in the case of stacks
    > and fork.


    how pessimistic would this be? i'll gladly trade a substantial
    chunk of memory for failure on allocation rather than failure
    on access.

    - erik


  4. Re: [9fans] plan 9 overcommits memory?

    Russ:
    | you could argue for some kind of accounting that would
    | ensure pages were available, but this could only be
    | terribly pessimistic, especially in the case of stacks
    | and fork.

    Still, that's the way unix worked. You can deal with the pessimism by
    allocating lots of backing store, whereas with overcommit (at least on
    linux) you just have to learn to live with processes dying randomly.

    But you knew all that.


  5. Re: [9fans] plan 9 overcommits memory?

    but most people can live with the overcommit, as witness the fact that
    most of us do and never know it.

    If you can't live with overcommit, maybe you need a wrapper that:
    sets up to catch the note (I am assuming here that you get one; do you?)
    malloc
    zero memory you malloc'ed (which will get the pages in)
    die reasonably if you get the note

    Would that work?

    ron

  6. Re: [9fans] plan 9 overcommits memory?

    > but most people can live with the overcommit, as witness the fact that
    > most of us do and never know it.
    >
    > If you can't live with overcommit, maybe you need a wrapper that:
    > sets up to catch the note (I am assuming here that you get one; do you?)
    > malloc
    > zero memory you malloc'ed (which will get the pages in)
    > die reasonably if you get the note


    but why introduce unpredictability? who really programs as if
    memory is not overcommited? i would bet that acme and most
    residents of /sys/src/cmd could do quite bad things to you in these
    cases. there's no waserror() in userland to wrap around memset.

    how much memory can be wasted by assuming that all brk'ed memory
    can be used?

    - erik


  7. Re: [9fans] plan 9 overcommits memory?

    > but most people can live with the overcommit, as witness the fact that
    > most of us do and never know it.
    >
    > If you can't live with overcommit, maybe you need a wrapper that:
    > sets up to catch the note (I am assuming here that you get one; do you?)
    > malloc
    > zero memory you malloc'ed (which will get the pages in)
    > die reasonably if you get the note


    but why introduce unpredictability? who really programs as if
    memory is not overcommited? i would bet that acme and most
    residents of /sys/src/cmd could do quite bad things to you in these
    cases. there's no waserror() in userland to wrap around memset.

    how much memory can be wasted by assuming that all brk'ed memory
    can be used?

    - erik


  8. Re: [9fans] plan 9 overcommits memory?

    On Sun, Sep 02, 2007 at 06:47:17PM -0700, ron minnich wrote:
    > If you can't live with overcommit, maybe you need a wrapper that:
    > sets up to catch the note (I am assuming here that you get one; do you?)


    That's still a race. Getting all the memory at once is different from
    probing for one page at a time and dealing with failures in the middle.


  9. Re: [9fans] plan 9 overcommits memory?

    >> malloc just moves the brk, but the backing pages don't get
    >> allocated until the pages are accessed (during memset).


    "erik quanstrom" wrote in message
    news:d7c705e9c3355e723c8f69677bf2d851@quanstro.net ...
    > i'm just suprised that plan 9 overcommits. this makes
    > this code nonsensical from user space
    > if((p = malloc(Size)) == 0)


    Indeed, when I discovered that Linux was overcommitting memory
    in much the same way, which in my view is erroneous design, I
    added an optional feature to my portable malloc implementation
    that (on systems neeing it) would touch every allocated page
    before reporting success. (During the touch loop a trap catcher
    would set a flag that would be tested after the loop to determine
    whether there had ben any faults.) malloc really shouldn't have
    to do this, but if you're insisting on overcommitment in the OS
    then the library malloc() needs to do it. Otherwise, applications
    that try to be careful may still fail "randomly", which is intolerable.

  10. Re: [9fans] plan 9 overcommits memory?

    "erik quanstrom" wrote in message
    news:d81b7ef468d08ecf9e31985f92a9b0c4@quanstro.net ...
    > but why introduce unpredictability? who really programs as if
    > memory is not overcommited?


    Practically everybody.

    > i would bet that acme and most
    > residents of /sys/src/cmd could do quite bad things to you in these
    > cases. there's no waserror() in userland to wrap around memset.


    You don't have to do that if malloc takes are of it. (See my nearby
    posting.)

    > how much memory can be wasted by assuming that all brk'ed memory
    > can be used?


    If you allocate the storage, presumably you should expect to use it.

    Anyway, it's better to be wasteful and correct than randomly failing.

  11. Re: [9fans] plan 9 overcommits memory?

    On 9/4/07, Douglas A. Gwyn wrote:
    >
    > >> malloc just moves the brk, but the backing pages don't get
    > >> allocated until the pages are accessed (during memset).

    >
    > "erik quanstrom" wrote in message
    > news:d7c705e9c3355e723c8f69677bf2d851@quanstro.net ...
    >
    > > i'm just suprised that plan 9 overcommits. this makes
    > > this code nonsensical from user space
    > > if((p = malloc(Size)) == 0)

    >
    > Indeed, when I discovered that Linux was overcommitting memory
    > in much the same way, which in my view is erroneous design, I
    > added an optional feature to my portable malloc implementation
    > that (on systems neeing it) would touch every allocated page
    > before reporting success. (During the touch loop a trap catcher
    > would set a flag that would be tested after the loop to determine
    > whether there had ben any faults.) malloc really shouldn't have
    > to do this, but if you're insisting on overcommitment in the OS
    > then the library malloc() needs to do it. Otherwise, applications
    > that try to be careful may still fail "randomly", which is intolerable.
    >


    Yep, I've seen code with totally erroneous use of realloc work perfectly on
    Linux for example, due to it's behavior. Then I built it on FreeBSD and it
    failed appropriately :-).

    The problem there, in my opinion, was not the OS's behavior, but the
    inexperience of the coder in question with realloc. The terrible side
    effect of all these garbage collected languages or ones that don't make you
    manage memory much is that programmers have this attitude that they aren't
    to blame when their code has flaws.

    Mac OS X has many options for testing malloc results as well. It can
    scribble on pages etc... I'm sure glibc has these options somewhere too.
    They're great testing tools.

    Dave


  12. Re: [9fans] plan 9 overcommits memory?

    On Tue Sep 4 09:39:37 EDT 2007, leimy2k@gmail.com wrote:

    > Yep, I've seen code with totally erroneous use of realloc work perfectly on
    > Linux for example, due to it's behavior. Then I built it on FreeBSD and it
    > failed appropriately :-).


    what does this have to do with memory overcommitment? k&r second ed,
    p. 252 specifies that malloc and realloc return NULL if the request can't
    be specified.

    - erik

  13. Re: [9fans] plan 9 overcommits memory?

    On 9/4/07, erik quanstrom wrote:
    >
    > On Tue Sep 4 09:39:37 EDT 2007, leimy2k@gmail.com wrote:
    >
    > > Yep, I've seen code with totally erroneous use of realloc work perfectly

    > on
    > > Linux for example, due to it's behavior. Then I built it on FreeBSD and

    > it
    > > failed appropriately :-).

    >
    > what does this have to do with memory overcommitment? k&r second ed,
    > p. 252 specifies that malloc and realloc return NULL if the request can't
    > be specified.
    >
    > - erik
    >


    Plenty if I shared the code with you... :-) Has to do with what memory was
    allocated vs what was being used.

    Unfortunately I'm not at liberty to post such code.


    Let's just say it shouldn't have returned NULL in this case (to my
    recollection). Different OSes behave differently with what is committed via
    the allocation functions of stdlib. I'm thinking they're creeping into
    undefined behavior territory of the standard rather than modes that are
    explicitly supposed to fail.

    Dave


  14. Re: [9fans] plan 9 overcommits memory?

    On 9/3/07, erik quanstrom wrote:
    > if((p = malloc(Size)) == 0)
    > /* malloc recovery code */
    > /* why bother? the kernel could be lying to us anyway. */


    Having run into issues writing codes with large memory footprints on
    linux (which also overcommits [by default]), erik's comment here is
    close to my heart. Indeed, what's the point of a malloc interface that
    returns 0 when in practice the kernel kills your process before that
    happens? It strikes me as irresponsible to advertise an interface you
    won't/can't honour.
    This is certainly my biggest problem with overcommitting. Well, that
    and the non determinism, but it's not clear to me that's avoidable
    when memory is exhausted.

    geoff@plan9.bell-labs.com wrote:
    > The big exception is stack growth. The
    > kernel automatically extends a process's stack segment as needed.


    OK, so the stack takes precedence over heap allocations. What if it
    was the other way around? Instead of stealing pages that process Y has
    malloc'd but not yet touched to grow the stack of process X, kill
    process X because there's not enough memory left to grow the stack...
    Mmmm. I don't think I helped anything. On the surface it looks like
    I'm honouring the malloc request, but there's probably a fair chance X
    == Y and the non-determinism really is the problem.

    Well, I guess the next question is: Is malloc's interface sufficient/practical?
    -sqweek

  15. Re: [9fans] plan 9 overcommits memory?

    On 9/4/07, sqweek wrote:

    > Well, I guess the next question is: Is malloc's interface sufficient/practical?


    sure. I use it all the time, I'm using it now.

    I use it several hundred times a second without knowing it, I bet.

    ron

  16. Re: [9fans] plan 9 overcommits memory?

    On 9/5/07, ron minnich wrote:
    > On 9/4/07, sqweek wrote:
    > > Well, I guess the next question is: Is malloc's interface sufficient/practical?

    >
    > sure. I use it all the time, I'm using it now.
    >
    > I use it several hundred times a second without knowing it, I bet.


    How many times does it return NULL?

+ Reply to Thread