mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Schwartz" <davids@webmaster.com>
To: "Timothy Miller" <miller@techsource.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: RE: Scheduler: Process priority fed back to parent?
Date: Wed, 17 Mar 2004 18:55:38 -0800	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKKEJBLCAA.davids@webmaster.com> (raw)
In-Reply-To: <200403161323.26043.eric@cisu.net>


> > I'm not familiar with that aspect of Windows, but... sure.  :)
>
> All i know is it does some sort of prefetch/caching of
> information to make
> user processes load faster.

	My recollection is that Windows, rather than letting a program and the
libraries it rely upon just fault in, keeps track of what pages from what
files it needed within its first few seconds of execution on a previous run
and pre-loads/maps them.

	If the startup access pattern of the program is quite random over multiple
files, this can save quite a bit of time because they can be loaded in in a
logical/sequential fashion. Otherwise, the operating system must load them
in in the order they fault because it has no idea what page will be needed
next as each fault blocks the process before it is known where the next
fault will be.

	Theoretically, one might expect Linux to benefit as well from such a
prefetch/preload mechanism. It would be interesting to code one as a quick
hack and see what kind of difference it makes. My guess is that Linux is
called upon to start behemoth programs much less often than Windows is.

	I also expect that the access patterns on Linux programs tends to be a bit
more linear than on Windows. If prefetching eliminates a large percentage of
the blocking faults, then there would be much less gain.

	On Windows 98, though, it made an enormous difference. The first add-on
programs to provide this type of optimization were amazing, especially when
you look at launch times for programs like Netscape that are large and span
muliple files.

	DS



      parent reply	other threads:[~2004-03-18  2:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-16 15:16 Timothy Miller
2004-03-16 15:46 ` Muli Ben-Yehuda
2004-03-16 16:19   ` Timothy Miller
2004-03-16 16:02     ` Muli Ben-Yehuda
2004-03-16 16:55       ` Timothy Miller
2004-03-16 18:49   ` Horst von Brand
2004-03-25 14:16     ` Pavel Machek
2004-03-16 16:06 ` Eric
2004-03-16 16:46   ` Timothy Miller
2004-03-16 19:23     ` Eric
2004-03-16 21:35       ` Timothy Miller
2004-03-16 23:05         ` Eric
2004-03-18  2:55       ` David Schwartz [this message]

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=MDEHLPKNGKAHNMBLJOLKKEJBLCAA.davids@webmaster.com \
    --to=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miller@techsource.com \
    /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

all inboxes | Powered by JetHome®