VM Requirement Document - v0.0

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.

Regards,
Dan

Personally, I'm in idea collection mode for that one. First things first, from my point of view, our basic replacement policy seems to be broken. The algorithms seem to be burning too much cpu and not doing enough useful work. Worse, they seem to have a nasty tendency to livelock themselves, i.e., get into situations where the mm is doing little other than scanning and transfering pages from list to list. IMHO, if these things were fixed much of the 'interactive problem' would go away because reloading the working set for the mouse, for example, would just take a few milliseconds. If not then we should take a good hard look at why the desktops have such poor working set granularity.

Furthermore, approaches that rely on applications touching what they believe to be their own working sets aren't going to work very well if the mm incorrectly processes the page reference information, or incorectly balances it against other things that might be going on, so lets be sure the basics are working properly. Marcello has the right idea with his attention to better memory management statistical monitoring. How nice it would be if he got together with the guy working on the tracing module...

That said, yes, it's good to think about hinting ideas, and maybe bless the idea of applications 'touching themselves' (yes, the allusion was intentional).

Here's an idea I just came up with while I was composing this... along the lines of using unused bandwidth for something that at least has a chance of being useful. Suppose we come to the end of a period of activity, the general 'temperature' starts to drop and disks fall idle. At this point we could consult a history of which currently running processes have been historically active and grow their working sets by reading in from disk. Otherwise, the memory and the disk bandwidth is just wasted, right? This we can do inside the kernel and not require coders to mess up their apps with hints. Of course, they should still take the time to reengineer them to reduce the cache footprint.

/me decides to stop spouting and write some code

--
Daniel

Well, on a laptop memory and disk bandwith are rarely wasted - they cost battery life.

Xav

Then turn the feature off.

--
Daniel

Let me comment on this again, having spent a couple of minutes more thinking about it. Would you be happy paying 1% of your battery life to get 80% less sluggish response after a memory pig exits?

Also, notice that the scenario we were originally discussing, the off-hours updatedb, doesn't normally happen on laptops because they tend to be suspended at that time.

--
Daniel

Told like this, of course I agree !

Suspended != halted. The updatedb stuff starts over when I bring it back to life (RH6.2, dunno for other distribs)

Xav

No, even worse, it happens when you open the laptop for the first time in the morning, thanks to anacron.

Alan Shutko <[email protected]> - In a variety of flavors!
For children with short attention spans: boomerangs that don't come back.

Just to pull a few random numbers out of my ass too, how about 50% of battery life for the same optimistic 80% less sluggishness ?

How about if it were only 30% of battery life?

Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"

		http://www.surriel.com/

http://www.conectiva.com/ http://distro.conectiva.com/

It's not as random as that. The idea being considered was: suppose a program starts up, goes through a period of intense, cache-sucking activity, then exits. Could we reload the applications it just displaced so that the disk activity to reload them doesn't have to take place the first time the user touches the keyboard/mouse. Sure, we obviously can, with how much complexity is another question entirely ;-)

So probably, we could eliminate more than 80% of the latency we now see in such a situation, I was being conservative.

Now what's the cost in battery life? Suppose it's a 128 meg machine, 1/3 filled with program text and data. Hopefully, the working sets that were evicted are largely coherent so we'll read it back in at a rate not too badly degraded from the drive's transfer rate, say 5 MB/sec. This gives about three seconds of intense reading to restore something resembling the previous working set, then the disk can spin down and perhaps the machine will suspend itself. So the question is, how much longer did the machine have to run to do this? Well, on my machine updatedb takes 5-10 minutes, so the 3 seconds of activity tacked onto the end of the episode amounts to less than 1%, and this is where the 1% figure came from.

I'm not saying this would be an easy hack, just that it's possible and the numbers work.

--
Daniel

Yes, but then it's normally overlapped with other work you are doing, like trying to read your mail. Different problem, one we also perform poorly at but for different reasons.

--
Daniel

Hi!

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...

Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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

Hi!

Application touching itself would be *evil*.

You might extend my approach if something like

if ps | grep gimp; then cat /usr/bin/gimp > /dev/null; fi

or something like that. It is definitely less evil than gimp doing it itself.

User programs should *never ever* do unneeded work. Touching itself is unneeded and evil for memory managment.

Agreed.
Pavel

The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+