From: Andrea Arcangeli <andrea@suse.de>
To: William Lee Irwin III <wli@holomorphy.com>,
Andrew Morton <akpm@digeo.com>,
Norman Gaywood <norm@turing.une.edu.au>,
linux-kernel@vger.kernel.org
Subject: Re: Maybe a VM bug in 2.4.18-18 from RH 8.0?
Date: Fri, 6 Dec 2002 23:28:52 +0100 [thread overview]
Message-ID: <20021206222852.GF4335@dualathlon.random> (raw)
In-Reply-To: <20021206024140.GL9882@holomorphy.com>
On Thu, Dec 05, 2002 at 06:41:40PM -0800, William Lee Irwin III wrote:
> No idea why there's not more support behind or interest in page
> clustering. It's an optimization (not required) for 64-bit/saner arches.
softpagesize sounds a good idea to try for archs with a page size < 8k
indeed, modulo a few places where the 4k pagesize is part of the
userspace abi, for that reason on x86-64 Andi recently suggested to
changed the abi to assume a bigger page size and I suggested to assume
it to be 2M and not a smaller thing as originally suggested, that way we
waste some more virtual space (not an issue on 64bit) and some cache
color (not a big deal either, those caches are multiway associative even
if not fully associative), so eventually in theory we could even switch
the page size to 2M ;)
however don't mistake softpagesize with the PAGE_CACHE_SIZE (the latter
I think was completed some time ago by Hugh). I think PAGE_CACHE_SIZE
is a broken idea (i'm talking about the PAGE_CACHE_SIZE at large, not
about the implementation that may even be fine with Hugh's patch
applied).
PAGE_CACHE_SIZE will never work well due the fragmentation problems it
introduces. So I definitely vote for dropping PAGE_CACHE_SIZE and to
experiment with a soft PAGE_SIZE, multiple of the hardware PAGE_SIZE.
That means the allocator minimal granularity will return 8k. on x86 that
breaks a bit the ABI. on x86-64 the softpagesize would breaks only the 32bit
compatibilty mode abi a little so it would be even less severe. And I
think the softpagesize should be a config option so it can be
experimented without breaking the default config even on x86.
the soft PAGE_SIZE will also decrease of an order of magnitude the page
fault rate, the number of pte will be the same but we'll cluster the pte
refills all served from the same I/O anyways (readhaead usually loads
the next pages too anyways). So it's a kind of quite obvious design
optimization to experiment with (maybe for 2.7?).
Andrea
next prev parent reply other threads:[~2002-12-06 22:21 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-06 0:13 Maybe a VM bug in 2.4.18-18 from RH 8.0? Norman Gaywood
2002-12-06 1:00 ` Andrew Morton
2002-12-06 1:17 ` Andrea Arcangeli
2002-12-06 1:34 ` Andrew Morton
2002-12-06 1:44 ` Andrea Arcangeli
2002-12-06 2:15 ` William Lee Irwin III
2002-12-06 2:28 ` Andrea Arcangeli
2002-12-06 2:41 ` William Lee Irwin III
2002-12-06 5:25 ` Andrew Morton
2002-12-06 5:48 ` Andrea Arcangeli
2002-12-06 6:14 ` William Lee Irwin III
2002-12-06 6:55 ` Andrew Morton
2002-12-06 7:14 ` GrandMasterLee
2002-12-06 7:25 ` Andrew Morton
2002-12-06 7:34 ` GrandMasterLee
2002-12-06 7:51 ` Andrew Morton
2002-12-06 11:37 ` Christoph Hellwig
2002-12-06 16:19 ` GrandMasterLee
2002-12-06 14:57 ` Andrea Arcangeli
2002-12-06 15:12 ` William Lee Irwin III
2002-12-06 23:32 ` Andrea Arcangeli
2002-12-06 23:45 ` William Lee Irwin III
2002-12-06 23:57 ` Andrea Arcangeli
2002-12-06 6:00 ` William Lee Irwin III
2002-12-06 22:28 ` Andrea Arcangeli [this message]
2002-12-06 23:21 ` William Lee Irwin III
2002-12-06 23:50 ` Andrea Arcangeli
2002-12-07 0:30 ` William Lee Irwin III
2002-12-07 0:01 ` Andrew Morton
2002-12-07 0:21 ` William Lee Irwin III
2002-12-07 0:30 ` Andrew Morton
2002-12-07 2:19 ` Alan Cox
2002-12-07 1:46 ` William Lee Irwin III
2002-12-07 1:56 ` Andrea Arcangeli
2002-12-07 2:31 ` Alan Cox
2002-12-07 2:09 ` William Lee Irwin III
2002-12-07 0:22 ` Andrea Arcangeli
2002-12-07 0:35 ` Andrew Morton
2002-12-07 0:46 ` William Lee Irwin III
2002-12-07 10:55 ` Arjan van de Ven
2002-12-06 10:36 ` Arjan van de Ven
2002-12-06 14:23 ` William Lee Irwin III
2002-12-06 15:12 ` William Lee Irwin III
2002-12-06 22:34 ` Andrea Arcangeli
2002-12-07 18:27 ` Eric W. Biederman
2002-12-06 1:08 ` Andrea Arcangeli
[not found] <mailman.1039133948.27411.linux-kernel2news@redhat.com>
2002-12-06 0:35 ` Pete Zaitcev
2002-12-06 1:27 ` Norman Gaywood
2002-12-06 12:48 ` 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=20021206222852.GF4335@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=norm@turing.une.edu.au \
--cc=wli@holomorphy.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