with overcommit enabled when a process forks the pages are marked COW and
no new memory is allocated (cache and buffers are untouched)
when overcommit is disabled and a process forks new memory is allocated,
but will this force cache and buffers to be thrown away (and possibly
force stuff out to swap) even if the memory is never written to? or does
the kernel still mark the pages COW, but somehow record that a chunk of
virtual memory (ram + swap) has been allocated for this without actually
affecting what's in ram?
my belief from watching the discussions is that it will evict things from
ram to make space for the new allocation, and as a result running with
overcommit disabled ends up wasting a noticable amount of ram. As a result
I leave overcommit enabled and create swap space large enough to handle
what I consider reasonable overloads (i.e. if I'm useing more swap than
what's allocated the machine is slmost certinly thrashing so much as to be
unusable)
but if I am wrong and the allocations actually can come from unused swap
space without pushing anything out of ram, then the right thing to do is
to disable overcommit and allocate a sizable chunk of swap space to get
a similar result as with overcommit, but without any possibility of the
OOM killer kicking in (at the cost that programs may fail memory
allocations instead)
could someone please clarify this for me?
David Lang
--
