lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0808280952010.2713@asgard.lang.hm>
Date:	Thu, 28 Aug 2008 10:00:20 -0700 (PDT)
From:	david@...g.hm
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: question about overcommit

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ