On Thu, Mar 27, 2008 at 10:50 AM, Balbir Singh
<balbir@linux.vnet.ibm.com> wrote:
Oops, after I'd written that I decided while describing it that maybe
it wasn't that fatal after all, just fiddly, and so deleted the
description but forgot to delete the preceding sentence. :-)
There were a couple of issues. The first was that if the new owner is
in a different cgroup, we might have to fix up the address space
charges when we pass off the ownership, which would be a bit of a
layer violation but maybe manageable.
The other was to do with ensuring that mm->owner remains valid until
after exit_mmap() has been called (so the va limit controller can
deduct from the va usage).
Java (or at least, Sun's JRE) is an example of a common application
that does this. It creates a huge heap mapping at startup, and faults
it in as necessary.
Well if I don't believe in per-container virtual address space limits,
I'm unlikely to be a big fan of system-wide virtual address space
limits either. So running with vm.overcommit_memory=2 is right out ...
I'm certainly not disputing that it's possible to avoid excessive
overcommit by using virtual address space limits.
It's just for that both of the real-world large-scale production
systems I've worked with (a virtual server system for ISPs, and
Google's production datacenters) there were enough cases of apps/jobs
that used far more virtual address space than actual physical memory
that picking a virtual address space ratio/limit that would be useful
for preventing dangerous overcommit while not breaking lots of apps
would be pretty much impossible to do automatically. And specifying
them manually requires either unusually clueful users (most of whom
have enough trouble figuring out how much physical memory they'll
need, and would just set very high virtual address space limits) or
sysadmins with way too much time on their hands ...
As I said, I think focussing on ways to tell apps that they're running
low on physical memory would be much more productive.
Paul
--
