lkml.org 
[lkml]   [1997]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux disk buffers -- how can we control it?

> i have implemented this recently, it's a 'swapin-predictor', completely
> kernel-based, it's similar to CPU branch prediction. It monitors per-vma
> swapin addresses, and maintains an array 'probable next swapin' pointers
> and probability counters. [...]

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


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.075 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site