Sorry to jump late in the game. Just few comments. On Thu 10-11-11 16:10:38, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/10/2011 02:43 PM, milan zimmermann wrote:
On Thu, Nov 10, 2011 at 10:15 AM, Jeff Mahoney <jeffm@suse.de> wrote: On 11/10/2011 11:06 AM, milan zimmermann wrote:
On Wed, Nov 9, 2011 at 3:41 PM, Jeff Mahoney <jeffm@suse.de> wrote: [...] You are right, that is how it works, I agree (my "disagree" was too harsh there :) ).
I should have said I am not sure with these particular flags ulimit should matter, as there should be no memory allocated (reserved). But I am only basic that on half-understanding this:
http://www.mjmwired.net/kernel/Documentation/vm/overcommit-accounting
(I think you are describing the difference below, also a question there)
I am, but there's another key difference here. There's a "max memory size" ulimit that controls actual allocations. The "virtual memory" one controls how much of the address space you can use. They're two separate things.
Yes, have a look at may_expand_vm (mm/mmap.c). It is called from all functions that manipulate your address space (do_brk - for heap allocation, acct_stack_growth - from the stack expand routine, mmap_region - for mmap calls, vma_to_resize - for mremap). ulimit is per-process while overcommit is per system. [...]
Overcommit covers memory use that is backed by memory itself plus any swap space you have.
Overcommit basically says how much we are willing to risk at the virtual memory allocation time (not backed by any real memory at the moment) that things will blow up when we fault that memory in (make it resident in the RAM). OVERCOMMIT_GUESS (0) - try to be intelligent and guess what could be dangerous (have a look at __vm_enough_memory for more details) OVERCOMMIT_ALWAYS (1) - says "hey we don't care and we can take a risk of bail out (OOM killer) if things go wrong" - seems to be the current banking model ;) OVERCOMMIT_NEVER (2) - be really strict that nobody allocates more than what is backed by a real memory (RAM+swap + a configurable percentage) As Jeff already noted this affects only anonymous memory and private writable file mappings because those cannot be just dropped to be re-read from the disk later. [...]
Take a look at /proc/<pid>/maps to see what I mean.
/proc/<pid>/smaps is even more descriptive. It will tell you how much memory from the mapping is resident, swapped out etc... [...] HTH Ragards -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org