Messages in this thread |  | | | Date | Thu, 16 Mar 2000 12:17:25 +0000 (GMT Standard Time) | | From | Paul Jakma <> | | Subject | Re: 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 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/
|  |