question about overcommit

[david@lang.hm]

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