> Wouldn't this problem be avoided if the kernel DIDN'T overcommit memory?
No.
First, it's not that easy to NOT overcommit memory. Sure, you can limit
brk(2) (i.e. malloc) pretty easily. Well, processes still need to be
able to grow their stacks... so we'll have to reserve 8-16M of RAM
every time we fork() in case they need their whole ulimit() of
stack space, PLUS all of the malloc()ed RAM of the parent (since it's
all copy-on-write now, and maybe the child will dirty all of it)
Now, account for all possible ram-usage in the kernel (page table mappings,
socket buffers, DMA bounce buffers, et al) that the user might be tying up
outside their own process space (the beancouter stuff is trying to address
that - not sure how far along that is though). This part of the problem is
addressable, but you need to ensure you have enough swap space to take
all the non-kernel allocations out of RAM, so your machine won't work
without swap no matter how much RAM you have.
Also, as others have already pointed out on the thread - what happens
now when a process tries to allocate more ram, and we fail since we're
not overcommitting? In all likelyhood, that process will die. By
not overcomitting we still let EvilUser take the machine just to the
brink of OOM and wreck complete havok (in this case, even fork(2)
will fail). If you're worried about run-away or malicious processes
hurting the machine, turning overcommit off makes it WORSE, since
there's no way that the bad process will be killed by the kernel.
> I mean, nobody tolerates their filesystem overcommitting blocks it
> doesn't have (or maybe they do and my reality is a myth).
Your reality IS a myth. If you have a sparse file, you can run out
of disk space while writing in the middle of it.
> Are the benefits to saying "uh, sure. we only have 600 megs of VM, but uh,
> feel free to let your system commit 1 gig" worth it? What makes that
> behavior desirable?
To make a functioning machine with absolutely NO overcommit would probably
require gigabytes of swap which would never be used, just to back the
stack pages and COW pages of all the processes. Plus, there's no real
gain to be had.
A full beancouting implementation would be much more useful. Then we could
do meaningful per-uid limits on usage and have OOM only affect the
responsible UIDs.
-Mitch
-
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 : Wed Mar 15 2000 - 21:00:23 EST