From: Daniel Phillips <phillips@bonn-fries.net>
To: Pavel Machek <pavel@suse.cz>, Dan Maas <dmaas@dcine.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: VM Requirement Document - v0.0
Date: Fri, 13 Jul 2001 01:46:54 +0200 [thread overview]
Message-ID: <0107130146540H.00409@starship> (raw)
In-Reply-To: <fa.jprli0v.qlofoc@ifi.uio.no> <002501c104f4/mnt/sendme701a8c0@morph> <20010709121736.B39@toy.ucw.cz>
In-Reply-To: <20010709121736.B39@toy.ucw.cz>
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
next prev parent reply other threads:[~2001-07-12 23:43 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.jprli0v.qlofoc@ifi.uio.no>
[not found] ` <fa.e66agbv.hn0u1v@ifi.uio.no>
2001-07-05 1:49 ` VM Requirement Document - v0.0 Dan Maas
2001-07-05 13:02 ` Daniel Phillips
2001-07-05 14:00 ` Xavier Bestel
2001-07-05 14:51 ` Daniel Phillips
2001-07-05 15:04 ` Daniel Phillips
2001-07-05 15:00 ` Xavier Bestel
2001-07-05 15:12 ` Daniel Phillips
2001-07-05 15:12 ` Alan Shutko
2001-07-06 19:09 ` Rik van Riel
2001-07-06 21:57 ` Daniel Phillips
[not found] ` <002501c104f4/mnt/sendme701a8c0@morph>
2001-07-09 12:17 ` Pavel Machek
2001-07-12 23:46 ` Daniel Phillips [this message]
2001-07-13 21:07 ` Pavel Machek
2001-07-05 15:09 mike_phillips
-- strict thread matches above, loose matches on Subject: below --
2001-07-04 16:08 mike_phillips
2001-06-28 12:20 mike_phillips
2001-06-28 12:30 ` Alan Cox
2001-06-28 13:33 ` Tobias Ringstrom
2001-06-28 13:37 ` Alan Cox
2001-06-28 14:04 ` Tobias Ringstrom
2001-06-28 14:14 ` Alan Cox
2001-06-28 14:52 ` Daniel Phillips
2001-06-28 14:39 ` Daniel Phillips
2001-06-28 15:21 ` Jonathan Morton
2001-06-28 16:02 ` Daniel Phillips
2001-06-28 18:01 ` Marco Colombo
2001-07-02 18:42 ` Rik van Riel
2001-07-03 10:33 ` Marco Colombo
2001-07-03 15:04 ` Daniel Phillips
2001-07-03 18:24 ` Daniel Phillips
2001-07-04 8:12 ` Ari Heitner
2001-07-04 9:41 ` Marco Colombo
2001-07-04 15:03 ` Daniel Phillips
2001-07-03 18:29 ` Daniel Phillips
2001-07-04 8:32 ` Marco Colombo
2001-07-04 14:44 ` Daniel Phillips
2001-06-27 8:53 Martin Knoblauch
2001-06-27 18:13 ` Rik van Riel
2001-06-28 6:59 ` Martin Knoblauch
2001-06-28 11:27 ` Helge Hafting
2001-06-28 11:54 ` Martin Knoblauch
2001-06-28 12:02 ` Tobias Ringstrom
2001-06-28 12:31 ` Xavier Bestel
2001-06-28 13:05 ` Tobias Ringstrom
[not found] <fa.oqkojpv.3hosb7@ifi.uio.no>
[not found] ` <fa.jpsks3v.1o2gag4@ifi.uio.no>
2001-06-27 0:43 ` Dan Maas
2001-06-27 0:45 ` Mike Castle
2001-06-27 10:50 ` Xavier Bestel
2001-06-26 19:58 Jason McMullan
2001-06-26 21:21 ` Rik van Riel
2001-06-26 21:29 ` Jason McMullan
2001-06-26 21:33 ` John Stoffel
2001-06-26 21:42 ` Rik van Riel
2001-06-26 22:21 ` Stefan Hoffmeister
2001-06-26 22:48 ` Jeffrey W. Baker
2001-06-27 0:18 ` Mike Castle
2001-06-28 13:07 ` John Fremlin
2001-06-27 13:36 ` Marco Colombo
2001-06-27 3:55 ` Daniel Phillips
2001-06-27 14:09 ` Pozsar Balazs
2001-06-28 22:47 ` John Fremlin
2001-06-30 15:37 ` Pavel Machek
2001-07-10 10:34 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0107130146540H.00409@starship \
--to=phillips@bonn-fries.net \
--cc=dmaas@dcine.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox