From: Nick Piggin <npiggin@suse.de>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Christoph Lameter <clameter@sgi.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-arch@vger.kernel.org
Subject: Re: [rfc] increase struct page size?!
Date: Sun, 20 May 2007 11:25:52 +0200 [thread overview]
Message-ID: <20070520092552.GA7318@wotan.suse.de> (raw)
In-Reply-To: <20070520084647.GF19966@holomorphy.com>
On Sun, May 20, 2007 at 01:46:47AM -0700, William Lee Irwin III wrote:
> On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote:
> >> The cache cost argument is specious. Even misaligned, smaller is
> >> smaller.
>
> On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote:
> > Of course smaller is smaller ;) Why would that make the cache cost
> > argument specious?
>
> It's not possible to ignore aggregation. For instance, for a subset
> of mem_map whose size ignoring alignment would otherwise fit in the
> cache to completely avoid sharing any cachelines between page
> structures requires page structures to be separated by at least one
> mem_map index. This is highly unlikely in uniform distributions.
But that wasn't my argument. I _know_ there are cases where the smaller
struct would be better, and I'm sure they would even arise in a running
kernel.
> On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote:
> >> The cache footprint reduction is merely amortized,
> >> probabilistic, etc.
>
> On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote:
> > I don't really know what you mean by this, or what part of my cache cost
> > argument you disagree with...
> > I think it is that you could construct mem_map access patterns, without
> > specifically looking at alignment, where a 56 byte struct page would suffer
> > about 75% more cache misses than a 64 byte aligned one (and you could also
> > get about 12% fewer cache misses with other access patterns).
> > I also think the kernel's mem_map access patterns would be more on the
> > random side, so overall would result in significantly fewer cache misses
> > with 64 byte aligned pages.
> > Which part do you disagree with?
>
> The lack of consideration of the average case. I'll see what I can smoke
> out there.
I _am_ considering the average case, and I consider the aligned structure
is likely to win on average :) I just don't have numbers for it yet.
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Christoph Lameter <clameter@sgi.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-arch@vger.kernel.org
Subject: Re: [rfc] increase struct page size?!
Date: Sun, 20 May 2007 11:25:52 +0200 [thread overview]
Message-ID: <20070520092552.GA7318@wotan.suse.de> (raw)
In-Reply-To: <20070520084647.GF19966@holomorphy.com>
On Sun, May 20, 2007 at 01:46:47AM -0700, William Lee Irwin III wrote:
> On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote:
> >> The cache cost argument is specious. Even misaligned, smaller is
> >> smaller.
>
> On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote:
> > Of course smaller is smaller ;) Why would that make the cache cost
> > argument specious?
>
> It's not possible to ignore aggregation. For instance, for a subset
> of mem_map whose size ignoring alignment would otherwise fit in the
> cache to completely avoid sharing any cachelines between page
> structures requires page structures to be separated by at least one
> mem_map index. This is highly unlikely in uniform distributions.
But that wasn't my argument. I _know_ there are cases where the smaller
struct would be better, and I'm sure they would even arise in a running
kernel.
> On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote:
> >> The cache footprint reduction is merely amortized,
> >> probabilistic, etc.
>
> On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote:
> > I don't really know what you mean by this, or what part of my cache cost
> > argument you disagree with...
> > I think it is that you could construct mem_map access patterns, without
> > specifically looking at alignment, where a 56 byte struct page would suffer
> > about 75% more cache misses than a 64 byte aligned one (and you could also
> > get about 12% fewer cache misses with other access patterns).
> > I also think the kernel's mem_map access patterns would be more on the
> > random side, so overall would result in significantly fewer cache misses
> > with 64 byte aligned pages.
> > Which part do you disagree with?
>
> The lack of consideration of the average case. I'll see what I can smoke
> out there.
I _am_ considering the average case, and I consider the aligned structure
is likely to win on average :) I just don't have numbers for it yet.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-05-20 9:25 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-18 4:08 [rfc] increase struct page size?! Nick Piggin
2007-05-18 4:08 ` Nick Piggin
2007-05-18 4:47 ` David Miller
2007-05-18 4:47 ` David Miller, Nick Piggin
2007-05-18 5:12 ` Nick Piggin
2007-05-18 5:12 ` Nick Piggin
2007-05-18 5:22 ` David Miller
2007-05-18 5:22 ` David Miller, Nick Piggin
2007-05-18 5:31 ` Nick Piggin
2007-05-18 5:31 ` Nick Piggin
2007-05-18 18:15 ` Christoph Lameter
2007-05-18 18:15 ` Christoph Lameter
2007-05-18 7:19 ` Andrew Morton
2007-05-18 7:19 ` Andrew Morton
2007-05-18 7:32 ` Nick Piggin
2007-05-18 7:32 ` Nick Piggin
2007-05-18 7:43 ` Andrew Morton
2007-05-18 7:43 ` Andrew Morton
2007-05-18 7:59 ` Nick Piggin
2007-05-18 7:59 ` Nick Piggin
2007-05-18 9:42 ` David Howells
2007-05-18 9:42 ` David Howells
2007-05-19 1:30 ` Nick Piggin
2007-05-19 1:30 ` Nick Piggin
2007-05-19 1:30 ` Nick Piggin
2007-05-18 12:06 ` Andi Kleen
2007-05-18 12:06 ` Andi Kleen
2007-05-18 15:42 ` Hugh Dickins
2007-05-18 15:42 ` Hugh Dickins
2007-05-19 1:22 ` Nick Piggin
2007-05-19 1:22 ` Nick Piggin
2007-05-19 17:53 ` William Lee Irwin III
2007-05-19 17:53 ` William Lee Irwin III
2007-05-20 22:50 ` Matthew Wilcox
2007-05-20 22:50 ` Matthew Wilcox
2007-05-18 18:14 ` Christoph Lameter
2007-05-18 18:14 ` Christoph Lameter
2007-05-18 20:37 ` Luck, Tony
2007-05-18 20:37 ` Luck, Tony
2007-05-18 20:37 ` Luck, Tony
2007-05-21 6:28 ` KAMEZAWA Hiroyuki
2007-05-21 6:28 ` KAMEZAWA Hiroyuki
2007-05-19 1:25 ` Nick Piggin
2007-05-19 1:25 ` Nick Piggin
2007-05-19 2:03 ` [rfc] increase struct page size?! (now sparsemem vmemmap) Christoph Lameter
2007-05-19 2:03 ` Christoph Lameter
2007-05-19 15:43 ` Andy Whitcroft
2007-05-19 15:43 ` Andy Whitcroft
2007-05-19 18:15 ` [rfc] increase struct page size?! William Lee Irwin III
2007-05-19 18:15 ` William Lee Irwin III
2007-05-19 18:25 ` Christoph Lameter
2007-05-19 18:25 ` Christoph Lameter
2007-05-20 4:10 ` Eric Dumazet
2007-05-20 4:10 ` Eric Dumazet
2007-05-20 12:56 ` Andi Kleen
2007-05-20 12:56 ` Andi Kleen
2007-05-21 17:08 ` Christoph Lameter
2007-05-21 17:08 ` Christoph Lameter
2007-05-22 0:30 ` KAMEZAWA Hiroyuki
2007-05-22 0:30 ` KAMEZAWA Hiroyuki
2007-05-22 0:38 ` Christoph Lameter
2007-05-22 0:38 ` Christoph Lameter
2007-05-22 0:58 ` KAMEZAWA Hiroyuki
2007-05-22 0:58 ` KAMEZAWA Hiroyuki
2007-05-22 9:44 ` Geert Uytterhoeven
2007-05-22 9:44 ` Geert Uytterhoeven
2007-05-19 22:09 ` Andrew Morton
2007-05-19 22:09 ` Andrew Morton
2007-05-20 7:26 ` William Lee Irwin III
2007-05-20 7:26 ` William Lee Irwin III
2007-05-21 9:12 ` Helge Hafting
2007-05-21 9:12 ` Helge Hafting
2007-05-21 9:45 ` Nick Piggin
2007-05-21 9:45 ` Nick Piggin
2007-05-20 5:22 ` Nick Piggin
2007-05-20 5:22 ` Nick Piggin
2007-05-20 8:46 ` William Lee Irwin III
2007-05-20 8:46 ` William Lee Irwin III
2007-05-20 9:25 ` Nick Piggin [this message]
2007-05-20 9:25 ` Nick Piggin
2007-05-21 8:08 ` William Lee Irwin III
2007-05-21 8:08 ` William Lee Irwin III
2007-05-21 9:27 ` Nick Piggin
2007-05-21 9:27 ` Nick Piggin
2007-05-21 11:26 ` William Lee Irwin III
2007-05-21 11:26 ` William Lee Irwin III
2007-05-22 0:52 ` Nick Piggin
2007-05-22 0:52 ` Nick Piggin
2007-05-21 22:43 ` Matt Mackall
2007-05-21 22:43 ` Matt Mackall
2007-05-22 1:08 ` Nick Piggin
2007-05-22 1:08 ` Nick Piggin
2007-05-22 1:13 ` Christoph Lameter
2007-05-22 1:13 ` Christoph Lameter
2007-05-22 1:39 ` William Lee Irwin III
2007-05-22 1:39 ` William Lee Irwin III
2007-05-22 1:57 ` Nick Piggin
2007-05-22 1:57 ` Nick Piggin
2007-05-22 5:04 ` William Lee Irwin III
2007-05-22 5:04 ` William Lee Irwin III
2007-05-22 6:24 ` Nick Piggin
2007-05-22 6:24 ` Nick Piggin
2007-05-22 10:59 ` William Lee Irwin III
2007-05-22 10:59 ` William Lee Irwin III
2007-05-21 9:31 ` Eric Dumazet
2007-05-21 9:31 ` Eric Dumazet
2007-05-21 17:06 ` Christoph Lameter
2007-05-21 17:06 ` Christoph Lameter
2007-05-20 17:13 ` Andrea Arcangeli
2007-05-20 17:13 ` Andrea Arcangeli
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=20070520092552.GA7318@wotan.suse.de \
--to=npiggin@suse.de \
--cc=clameter@sgi.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.