Re: Kernel 2.6.8.1: swap storm of death - nr_requests > 1024 on swap partition

Karl Vogel
2004-08-28T21:59:57Z

Andrew Morton wrote:

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

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