Andrew Morton wrote:

quoted

So if I understand you correctly, CFQ shouldn't be using 8192 on 512Mb 
systems?!

Yup.  It's asking for trouble to allow that much memory to be unreclaimably
pinned.

Of course, you could have the same problem with just 128 requests per
queue, and lots of queues.  I solved all these problems in the dirty memory
writeback paths.  But I forgot about swapout!

Looks like the default 128 requests that AS is using, also gives trouble 
with 128Mb systems. I just tried booting with mem=128M and then doing:

  $ while true; do expunge 130; done

which causes the OOM to kick in too. Decreasing nr_requests resolves the 
issue.
So it's not only with lots of queues (AS only uses 1 queue, right?)

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.

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

NOTE: this happens both with overcommit_memory set to 0 or 1.

--
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>