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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
