On Wed, 25 Jun 2014 08:58:46 +0100 Mel Gorman <mgorman@xxxxxxx> wrote: > Historically kswapd scanned from DMA->Movable in the opposite direction > to the page allocator to avoid allocating behind kswapd direction of > progress. The fair zone allocation policy altered this in a non-obvious > manner. > > Traditionally, the page allocator prefers to use the highest eligible zone > until the watermark is depleted, woke kswapd and moved onto the next zone. > kswapd scans zones in the opposite direction so the scanning lists on > 64-bit look like this; > > ... > > Note that this patch makes a large performance difference for lower > numbers of threads and brings performance closer to 3.0 figures. It was > also tested against xfs and there are similar gains although I don't have > 3.0 figures to compare against. There are still regressions for higher > number of threads but this is related to changes in the CFQ IO scheduler. > Why did this patch make a difference to sequential read performance? IOW, by what means was/is reclaim interfering with sequential reads? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>