Richard Stallman writes:
> Well, while it would be a good option to have, I'm not sure it's a
> good idea to make it the default. If you flush the buffer+page caches,
> then later you will need to repopulate them.
>
> It is worth caching data, in ordinary circumstances, because it has
> a certain chance of being useful and caching costs essentially
> nothing. But often the data will never be used again. It is not
> worth waiting to write and then reread many megabytes of cached
> data.
Sure, you don't want to cache stuff you don't need. But the OS doesn't
know if you'll need it later or not. Hence the default should be to
preserve the caches (since random repopulation is slower).
For example, when kernel hacking, I like to keep the kernel sources in
my caches. This speeds up global searches and compiles. After a
suspend, I want to read it back from a linear section of disc rather
than seeking about like when then cache is cold.
> What would be nicer is if when you suspend, you record the cached
> block numbers (and then flush+clear the caches), and on resume kick
> off a daemon/kernel thread which touches those blocks, bringing them
> back into the caches.
>
> If this is done in background, whenever there is no other disk
> activity, it could not do any harm.
The trick is reliably determining when there is no other disc
activity. A simple heuristic is to watch the load average, but that
falls over when you start repopulating the caches and then the user
triggers immediate I/O. So really you want prioritised I/O.
Also, you need a kernel hook to find which dev,inode,block tuples are
sitting in the caches.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:23 EST