improve streaming I/O [bug in shrink_mmap()]

Quoted 11 lines · Zlatko Calusic

Quoted 9 lines

This simple one-liner solves a long standing problem in Linux VM. While searching for a discardable page in shrink_mmap() Linux was too easily failing and subsequently falling back to swapping. The problem was that shrink_mmap() counted pages from the wrong zone, and in case of balancing a relatively smaller zone (e.g. DMA zone on a 128MB computer) "count" would be mistakenly spent dealing with pages from the wrong zone. The net effect of all this was spurious swapping that hurt performance greatly.

Quoted 2 lines

Nice --- it might also explain some of the excessive kswap CPU utilisation we've seen reported now and again.

Indeed. And to be honest, the patch can be made even simpler.

We can simply move the test up to above the count--, so we won't start IO for the "wrong" zones either.

There's only one serious bug left with the current shrink_mmap, a bug which appears to be easy to trigger with this patch, but still there without it.

Consider the case where only one zone has free_pages < pages_high, but all the pages in the LRU queue are from the other zone or not freeable (ie. with pagetable mapping)...

In those cases shrink_mmap() can loop forever. We probably want to add a "maxscan" variable, initialised to nr_lru_pages, which is decremented on every iteration through the loop to prevent us from triggering this bug.