[lkml]   [2000]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Overcommitable memory??
    On Thu, 16 Mar 2000, James Sutherland wrote:

    > It CAN be, if you WANT it to. (/proc/sys/vm/overcommit).

    no it can't. Read the description of this carefully, and have a look at
    the function reffered to in the docs to see what it does. It doesn't
    disable overcommit (linux doesn't have enough vm accounting to do that
    anyway) - it has the exact opposite effect.

    > I don't have this
    > enabled, though, and I haven't changed this setting.

    makes no difference, the choice is between overcommit and overcommit
    with even the basic memory free checks disabled.

    > Something grabbed all the memory. Just running while(1){malloc(4096);}
    > will do this quite easily,

    will it? Go and try the above on a linux box. It won't kill it last time
    i checked. Unless you actually try to access the memory you've
    malloc()'ed. (cause it's overcommited by default)

    > Yes - in practice, we really need the latter, though.

    i think most people are agreed on that. per user limits would be real

    > Unless you have specifically enabled this

    ah ok.. i see what you are driving at. You're saying the
    overcommit_memory sysctl enables overcommit on malloc(). And yes
    (aisi) it does that - well actually it enables 'super-overcommit'.

    Where i think you are wrong is that you seem to think that with
    overcommit_memory=0 that malloc()'s are properly reserved and accounted

    But I'm pretty sure you are wrong. aisi overcommit_memory=0 just means
    the kernel does a quick general check of how much memory is left
    over, ie it checks that malloc request < total memory - memory already
    /fully/ allocated. (it doesn't account for overcommited memory, cause
    it can't)

    have a look at the vm_enough_memory function referred to in
    Documentation/sysctl/vm.txt (i think vm_enough_memory() is in vm/mmap.c
    iirc) to see what i mean, and why i think malloc() is overcommited.

    > , malloc() shouldn't be
    > overcommitted - you call malloc() and get some memory, and it's yours.
    > It's only things like fork(), where you only have "fake" memory (it's
    > really shared with someone else until you write to it), that overcommit
    > takes effect otherwise.

    aiui you're mistaken. i really don't think the kernel either allocates
    real memory for malloc() at time of malloc(), or that the kernel does
    the proper accounting to allow it.

    (but i'm willing to be educated if wrong :) preferably with pointers to
    the appropriate function )

    > James.


    Paul Jakma.

    PS: this is pretty much an argument between ourselves, and not of much
    use to the OOM discussion. We should take it to private email. I post
    this to l-k just in case a linux VM guru might be kind enough to settle
    our debate.

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