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
nice..
> 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
for.
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.
>
regards,
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:18 EST