Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: Suggestion for laptop suspension | Date | Sun, 27 Aug 2000 16:43:54 +0200 |
| |
Richard Stallman wrote: > On my laptop, suspending to disk is slow. It takes a whole minute, and > another minute to unsuspend--if all of core is in use. But it is much > faster when I do it not too long after the system was booted, when it has > not yet managed to use up most of core. > > This suggests that it could be nice to make the kernel empty its caches, and > mark all that core "unused", when a suspend is about to happen. I don't > know the details of how suspension works, so I am not sure this is possible, > but I think there are hooks for doing something in the kernel before a > suspend.
There are other good reasons why users should be able to tell the kernel to shrink its caches. For example, throwing away the cache to force actual device accesses would help determine if low-level file and device I/O are working correctly. An example for normal users: you might be aware that some big job that filled up the caches is now finished, and so the caches can be shrunk immediately instead of piecemeal as other applications try to get memory. As user, you are sometimes in a much better position to know when to shrink the caches than the OS is.
Note that it is not enough just to mark the memory as unused, it must also be cleared so that the bios can compress it to disk quickly and effectively. The bios doesn't really know which memory is in use - when it does its save/restore it has to recreate the entire contents of physical memory exactly. Saving/restoring pages consisting entirely of zeros is obviously going to be a lot faster, and a trivial compression algorithm will produce good results.
For you and for me, having some sort of cache-shrinking feature in the form of a patch (as opposed to built into the kernel) would be entirely adequate. You get your laptop working better and I can debug my filesystem in greater comfort. So now all you have to do is convince someone to write the patch. It wouldn't be hard to write - a lot of cache-shrinking code is already there in the kernel. In fact, there are already a number of hooks in /proc for controlling various limits on vm usage, but what we really want is one, nice simple way.
For example, you could have a /proc/sys/vm/size into which you echo your new, desired physical memory size (say: 0). Your proc handler would then attempt to achieve that size by shrinking various caches and/or swapping out. Cat'ing /proc/sys/vm/size would tell you roughly what size was achieved. In both cases this is advisory: your system shrinker probably isn't going to give you exactly the size you asked for, nor will it stay at the reported size for very long. As I mentioned before, for this to help you with your laptop you also have to arrange for all that free memory to be clear and that's probably where most of the work would go.
-- Daniel - 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/
|  |