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?
Thanks!
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
