Re: How can we make page replacement smarter (was: swap-prefetch)
From: Robert Hancock
Date: Sat Jul 28 2007 - 12:33:25 EST
Al Boldi wrote:
Chris Snook wrote:
Al Boldi wrote:
Because it is hard to quantify the expected swap-in speed for random
pages, let's first tackle the swap-in of consecutive pages, which should
be at least as fast as swap-out. So again, why is swap-in so slow?
If I'm writing 20 pages to swap, I can find a suitable chunk of swap and
write them all in one place. If I'm reading 20 pages from swap, they
could be anywhere. Also, writes get buffered at one or more layers of
hardware.
Ok, this explains swap-in of random pages. Makes sense, but it doesn't
explain the awful tmpfs performance degradation of consecutive read-in runs
from swap, which should have at least stayed constant
At best, reads can be read-ahead and cached, which is why
sequential swap-in sucks less. On-demand reads are as expensive as I/O
can get.
Which means that it should be at least as fast as swap-out, even faster
because write to disk is usually slower than read on modern disks. But
linux currently shows a distinct 2x slowdown for sequential swap-in wrt
swap-out. And to prove this point, just try suspend to disk where you can
see sequential swap-out being reported at about twice the speed of
sequential swap-in on resume. Why is that?
Depends if swap-in is doing any read-ahead. If it's reading one page at
a time in from the disk then the performance will definitely suck
because of all the overhead from the tiny I/O's. With random swap-in you
then pay the horrible seek penalty for all the reads as well.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@xxxxxxxxxxxxx
Home Page: http://www.roberthancock.com/
-
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/