From: "Stephen C. Tweedie" <sct@redhat.com>
To: Gerard Roudier <groudier@club-internet.fr>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
Rik van Riel <H.H.vanRiel@phys.uu.nl>,
Linux MM <linux-mm@kvack.org>,
Linux Kernel <linux-kernel@vger.rutgers.edu>
Subject: Re: [PATCH] swapin readahead and fixes
Date: Mon, 7 Dec 1998 16:50:44 GMT [thread overview]
Message-ID: <199812071650.QAA05697@dax.scot.redhat.com> (raw)
In-Reply-To: <Pine.LNX.3.95.981205102900.449A-100000@localhost>
Hi,
On Sat, 5 Dec 1998 10:46:40 +0100 (MET), Gerard Roudier
<groudier@club-internet.fr> said:
> You may perform read-ahead when you really swap in a process that had been
> swapped out. But about paging, you must consider that this mechanism is
> not sequential but mostly ramdom in RL. So you just want to read more data
> at the same time and near the location that faulted. Reading-ahead is
> obviously candidate for this optimization, but reading behind must also be
> considered in my opinion.
Yep: one of the things which has been talked about, and which is on my
list of things to start experimenting with in 2.3, is increasing the
granularity of paging so that we automatically try to read in (say) 16K
at a time when we start paging a binary. Discarding unused pages can
still work on a per-page granularity, so we don't bloat memory in the
long term, but it has the potential to significantly improve loading
times for some binaries.
Of course, there are also a whole number of optimisations we can make
explicitly for sequentially accessed mapped regions, but the granularity
trick should be a pretty cheap way to wring a bit more performance out
of the normal random paging.
--Stephen
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next prev parent reply other threads:[~1998-12-07 16:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-12-03 17:56 Rik van Riel
1998-12-04 11:34 ` Stephen C. Tweedie
1998-12-04 14:02 ` Rik van Riel
1998-12-04 14:34 ` Stephen C. Tweedie
1998-12-05 9:46 ` Gerard Roudier
1998-12-07 16:50 ` Stephen C. Tweedie [this message]
1998-12-08 1:34 ` Billy Harvey
1998-12-08 2:31 ` Rik van Riel
1998-12-08 2:51 ` Billy Harvey
1998-12-08 3:00 ` Rik van Riel
1998-12-08 12:35 ` Stephen C. Tweedie
1998-12-08 13:51 ` Rik van Riel
1998-12-09 2:41 ` Drago Goricanec
1998-12-09 11:58 ` Stephen C. Tweedie
1998-12-08 12:21 ` Stephen C. Tweedie
1998-12-05 10:47 ` Gerard Roudier
1998-12-04 19:25 ` Chris Evans
1998-12-04 20:47 ` Rik van Riel
1998-12-05 18:59 ` Alan Cox
1998-12-05 19:02 ` Rik van Riel
1998-12-06 5:20 ` Rik van Riel
1998-12-06 5:23 ` Steve VanDevender
1998-12-07 11:52 ` Rik van Riel
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=199812071650.QAA05697@dax.scot.redhat.com \
--to=sct@redhat.com \
--cc=H.H.vanRiel@phys.uu.nl \
--cc=groudier@club-internet.fr \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
/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