vmscan: delegate pageout io to flusher thread if current is kswapd
in [Kernel]
|
Prev: integrating KDB with linux kernel
Next: perf & kvm: Enhance perf to collect KVM guest os statistics from host side
From: KOSAKI Motohiro on 15 Apr 2010 07:30 > On Thu, Apr 15, 2010 at 01:11:37PM +0900, KOSAKI Motohiro wrote: > > Now, vmscan pageout() is one of IO throuput degression source. > > Some IO workload makes very much order-0 allocation and reclaim > > and pageout's 4K IOs are making annoying lots seeks. > > > > At least, kswapd can avoid such pageout() because kswapd don't > > need to consider OOM-Killer situation. that's no risk. > > > > Well, there is some risk here. Direct reclaimers may not be cleaning > more pages than it had to previously except it splices subsystems > together increasing stack usage and causing further problems. > > It might not cause OOM-killer issues but it could increase the time > dirty pages spend on the LRU. > > Am I missing something? No. you are right. I fully agree your previous mail. so, I need to cool down a bit ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Suleiman Souhlal on 15 Apr 2010 13:30
On Apr 15, 2010, at 3:30 AM, Johannes Weiner wrote: > On Thu, Apr 15, 2010 at 05:26:27PM +0900, KOSAKI Motohiro wrote: >> >> Hannes, if my remember is correct, you tried similar swap-cluster IO >> long time ago. now I can't remember why we didn't merged such patch. >> Do you remember anything? > > Oh, quite vividly in fact :) For a lot of swap loads the LRU order > diverged heavily from swap slot order and readaround was a waste of > time. > > Of course, the patch looked good, too, but it did not match reality > that well. > > I guess 'how about this patch?' won't get us as far as 'how about > those numbers/graphs of several real-life workloads? oh and here > is the patch...'. > >>>> Cluster writes to disk due to memory pressure. >>>> >>>> Write out logically adjacent pages to the one we're paging out >>>> so that we may get better IOs in these situations: >>>> These pages are likely to be contiguous on disk to the one >>>> we're >>>> writing out, so they should get merged into a single disk IO. >>>> >>>> Signed-off-by: Suleiman Souhlal <suleiman(a)google.com> > > For random IO, LRU order will have nothing to do with mapping/disk > order. Right, that's why the patch writes out contiguous pages in mapping order. If they are contiguous on disk with the original page, then writing them out as well should be essentially free (when it comes to disk time). There is almost no waste of memory regardless of the access patterns, as far as I can tell. This patch is just a proof of concept and could be improved by getting help from the filesystem/swap code to ensure that the additional pages we're writing out really are contiguous with the original one. -- Suleiman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |