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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:19 EST