Re: [patch v3] swap: virtual swap readahead

[Johannes Weiner]

On Sun, Jun 21, 2009 at 07:07:03PM +0100, Hugh Dickins wrote:
> Hi Hannes,
> 
> On Thu, 18 Jun 2009, Johannes Weiner wrote:
> > On Thu, Jun 18, 2009 at 05:19:49PM +0800, Wu Fengguang wrote:
> > 
> > Okay, evaluating this test-patch any further probably isn't worth it.
> > It's too aggressive, I think readahead is stealing pages reclaimed by
> > other allocations which in turn oom.
> > 
> > Back to the original problem: you detected increased latency for
> > launching new applications, so they get less share of the IO bandwidth
> > than without the patch.
> > 
> > I can see two reasons for this:
> > 
> >   a) the new heuristics don't work out and we read more unrelated
> >   pages than before
> > 
> >   b) we readahead more pages in total as the old code would stop at
> >   holes, as described above
> > 
> > We can verify a) by comparing major fault numbers between the two
> > kernels with your testload.  If they increase with my patch, we
> > anticipate the wrong slots and every fault has do the reading itself.
> > 
> > b) seems to be a trade-off.  After all, the IO resources you have less
> > for new applications in your test is the bandwidth that is used by
> > swapping applications.  My qsbench numbers are a sign for this as the
> > only IO going on is swap.
> > 
> > Of course, the theory is not to improve swap performance by increasing
> > the readahead window but to choose better readahead candidates.  So I
> > will run your tests and qsbench with a smaller page cluster and see if
> > this improves both loads.
> 
> Hmm, sounds rather pessimistic; but I've not decided about it either.

It seems the problem was not that real after all:

	http://lkml.org/lkml/2009/6/18/109

> May I please hand over to you this collection of adjustments to your
> v3 virtual swap readahead patch, for you to merge in or split up or
> mess around with, generally take ownership of, however you wish?
> So you can keep adjusting shmem.c to match memory.c if necessary.

I will adopt them, thank you!

	Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/