then it goes and does asynchron readahead as far as there is more than 50%
of probability to get the next swapin right. (eg. in a 0.8 -> 0.9 -> 0.7
-> 0.6 chain, only the first three async swapins will be done, and we wait
for the first one to complete before starting the 0.6 probability one]
> It does improve the speed of linear trashing
> _alot_ ;) (from 80K/sec to disk speed) Not that linear trashing is a good
> thing.
basically it improves every swapin activity, that has some non-random
local component. measurement shows that 90% of all swap activities are
such. This does _not_ include readpage() swapins, only swap partitions!
actually, this hack was a side-effect of read prediction / active
migration/serializing hacks done on persistant filesystems. But the
persistant storage stuff is really hard, due to the size of prediction
tables and due to crash-recovery requirements. (none of these is an issue
for swap devices)
-- mingo