Here are two situations:
You have a machine with a very slow | You have a very very fast but small
drive, say one of these new 'fast' CD | drive that you can put your swap
roms with the 10 second spin up time | space on, perhaps you've got your
or a file system on a tape like | hands on a real silicon disk drive,
device. This drive looks much like a | probably it's that RAM that the MBo
normal hard drive but is _slooooooow_ | can't cache 'cause 'doze never uses
| it.
Call this drive B. Drive A is a |
normal hard disk with a nice large | Call this drive A. Drive B is a
swap space on it. | normal hard disk with all your
| filesystems on it.
When swapping the kernel 'knows' that it is much cheaper to discard clean
pages that have to be re-read from drive B than it is to save a dirty page
to the swap space on drive A. Normally with all drives created equal this
is very true so it's stupid to cache disks in the swap space. But in this
case Drive A can be so much faster than Drive B that any free space on it
could be reasonably used as a cache for B.
I think that, at a user level, it might be possible to link this into the
current swap priority scheme by assigning an negitive priority to very slow
filesystems so that if the priorities are 'sufficiently far apart' the
swapper can be made to realise that cacheing is reasonable.
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.
So, who knows the kernel well enough to do this? :-)
--
Rob. (Robert de Bath <http://www.cix.co.uk/~mayday>)
<http://poboxes.com/rdebath>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu