public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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