William Lee Irwin III [off-list ref] wrote:

Karl Vogel [off-list ref] wrote:

quoted

quoted

With overcommit_memory set to 1, the program can be run again after the 
OOM kill.. but the OOM killing remains.
With overcommit_memory set to 0 a second run fails. I 'think' it's 
because somehow SwapCache is 500Kb after the OOM, so in effect my system 
doesn't have 1Gb to spare anymore. Doing swapoff/swapon frees this and 
then I can do the calloc(1Gb) again.
Another way to free the SwapCached is to generate lots of I/O doing 'dd 
if=/dev/hda of=/dev/null' ... after a while SwapCached is < 1Mb again.

On Sat, Aug 28, 2004 at 02:43:03PM -0700, Andrew Morton wrote:

quoted

urgh.  It sounds like the overcommit logic forgot to account swapcache as
reclaimable.  It's been a ton of trouble, that code.

For overcommit purposes, swapcache still counts as committed AS; it
requires swap as backing store to evict. So AFAICT there isn't an issue
there.

But that backing store is allocated?

I was under the impression this had something to do with IO
schedulers.

Separate issue.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>