* Con Kolivas <[EMAIL PROTECTED]> wrote:
> It turns out that fixing swap prefetch was not that hard to fix and
> improve upon, and since Andrew hasn't dropped swap prefetch, instead
> here are a swag of fixes and improvements, [...]
it's a reliable win on my testbox too:
# echo 1 > /proc/sys/vm/swap_prefetch
# ./sp_tester
Ram 1019540000 Swap 4096564000
Total ram to be malloced: 1529310000 bytes
Starting first malloc of 764655000 bytes
Starting 1st read of first malloc
Touching this much ram takes 4393 milliseconds
Starting second malloc of 764655000 bytes
Completed second malloc and free
Sleeping for 600 seconds
Important part - starting reread of first malloc
Completed read of first malloc
Timed portion 30279 milliseconds
versus:
# echo 0 > /proc/sys/vm/swap_prefetch
# ./sp_tester
[...]
Timed portion 36605 milliseconds
i've repeated these tests to make sure it's a stable win and indeed it
is:
# swap-prefetch-on:
Timed portion 29704 milliseconds
# swap-prefetch-off:
Timed portion 34863 milliseconds
Nice work Con!
A suggestion for improvement: right now swap-prefetch does a small bit
of swapin every 5 seconds and stays idle inbetween. Could this perhaps
be made more agressive (optionally perhaps), if the system is not
swapping otherwise? If block-IO level instrumentation is needed to
determine idleness of block IO then that is justified too i think.
Another suggestion: swap-prefetch seems to be doing all the right
decisions in the sp_test.c case - so would it be possible to add
statistics so that it could be verified how much of the swapped-in pages
were indeed a 'hit' - and how many were recycled without them being
reused? That could give a reliable, objective metric about how efficient
swap-prefetch is in any workload.
Ingo
-
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/
