> In concept I suppose it's just extending the unified buffer cache to more
> levels so the concept should be simple ...
>
> A nice point for the left hand case is that these pages could stay in the
> cache for days (weeks?) if it's large enough ... who needs a fast CDROM ?
>
> Then I bet there are people who'd want both the left an right cases at the
> same time.
We'd probably want another optimization taking place:
- for every drive, nr_request_per_minute / response_time = equal,
ie, if one drive is twice as fast in request servicing, we should
tweak our VM/buffer system in such a way that the fast drive gets
twice as many requests as the slow one...
Good sysadmins do something like this by hand, by placing the
proper filesystems on the proper disk, but it never hurts to
balance things even more...
We can do this by adding a 'cost-to-replace-factor' pointer to
every page and computing the actual cost factor on a per drive
basis. Swapping can be done to the 'cheapest' disk.
Rik.
+-------------------------------------------+--------------------------+
| Linux: - LinuxHQ MM-patches page | Scouting webmaster |
| - kswapd ask-him & complain-to guy | Vries cubscout leader |
| http://www.fys.ruu.nl/~riel/ | <H.H.vanRiel@fys.ruu.nl> |
+-------------------------------------------+--------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu