[lkml]   [2007]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: How can we make page replacement smarter (was: swap-prefetch)
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
Home Page:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-07-28 18:35    [W:0.021 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site