Re: VM Requirement Document - v0.0

Daniel Phillips (phillips@bonn-fries.net)
Fri, 13 Jul 2001 01:46:54 +0200


On Monday 09 July 2001 14:17, Pavel Machek wrote:
> > Possibly stupid suggestion... Maybe the interactive/GUI programs
> > should wake up once in a while and touch a couple of their pages?
> > Go too far with this and you'll just get in the way of performance,
> > but I don't think it would hurt to have processes waking up every
> > couple of minutes and touching glibc, libqt, libgtk, etc so they
> > stay hot in memory... A very slow incremental "caress" of the
> > address space could eliminate the
> > "I-just-logged-in-this-morning-and-dammit-everything-has-been-paged
> >-out" problem.
>
> Ugh... Ouch.... Ugly, indeed.
>
> What you might want to do is
>
> while true; do
> cat /usr/lib/libc* > /dev/null; sleep 1m
> cat /usr/lib/qt* > /dev/null; sleep 1m
> ...
> done
>
> running on your system...

90%+ of what you touch that way is likely to be outside your working
set, and only the libraries get pre-loaded, not the application code or
data. An approach where the application 'touches itself' has more
chance of producing a genuine improvement in response, but is that
really what we want application programmers spending their time
writing? Not to mention the extra code bloat and maintainance overhead.

Maybe there are a some applications out there - perhaps a database that
for some reason needs to minimize its latency - where the effort is
worth it, but they're few and far between. IMHO, only a generic
facility in the operating system is going to result in anything that's
worth the effort to implement it.

What would be needed is some kind of memory of swapped out process
pages so that after one application terminates some pages of another,
possibly idle process could be read back in. Naturally, this would
only be done if the system resources were otherwise unused. This
optimization in the same category as readahead - it serves to reduce
latency - but it provides a benefit only in one specific circumstance.
On the other hand, the place where it does improve things is highly
visible, so I don't know, it might be worth trying some experiments
here. Not now though, a mature, well-understood vm system is a
prerequisite.

Well, I just thought of one relatively simple thing that could be done
in the desktop - redraw the screen after a big app exits and the system
is otherwise idle. That at least would page some bitmaps back in and
touch some drawing methods. The responsibility for detecting the
relevant condition would lie with the OS and there would be some
as-yet-undefined mechanism for notifying the desktop.

This is firmly in the flight-of-fancy category. What would be real and
worth doing right now is for some application developers to profile
their wonderful creations and find out why they're touching so darn
much memory. Who hasn't seen their system go into a frenzy as the
result of bringing up a simple configuration dialog in KDE? Or
right-clicking one of the window buttons in Gnome? It's uncalled for,
a little effort on that front would make the restart latency problem
mostly go away.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/