From: William Lee Irwin III <wli@holomorphy.com>
To: Nick Piggin <npiggin@suse.de>
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: Mon, 21 May 2007 04:26:03 -0700 [thread overview]
Message-ID: <20070521112603.GJ19966@holomorphy.com> (raw)
In-Reply-To: <20070521092742.GA19642@wotan.suse.de>
On Mon, May 21, 2007 at 01:08:13AM -0700, William Lee Irwin III wrote:
>> Choosing k distinct integers (mem_map array indices) from the interval
>> [0,n-1] results in k(n-k+1)/n non-adjacent intervals of contiguous
>> array indices on average. The average interval length is
>> (n+1)/(n-k+1) - 1/C(n,k). Alignment considerations make going much
>> further somewhat hairy, but it should be clear that contiguity arising
>> from random choice is non-negligible.
On Mon, May 21, 2007 at 11:27:42AM +0200, Nick Piggin wrote:
> That doesn't say anything about temporal locality, though.
It doesn't need to. If what's in the cache is uniformly distributed,
you get that result for spatial locality. From there, it's counting
cachelines.
On Mon, May 21, 2007 at 01:08:13AM -0700, William Lee Irwin III wrote:
>> In any event, I don't have all that much of an objection to what's
>> actually proposed, just this particular cache footprint argument.
>> One can motivate increases in sizeof(struct page), but not this way.
On Mon, May 21, 2007 at 01:08:13AM -0700, William Lee Irwin III wrote:
> Realise that you have to have a run of I think at least 7 or 8 contiguous
> pages and temporally close references in order to save a single cacheline.
> Then also that if the page being touched is not partially in cache from
> an earlier access, then it is statistically going to cost more lines to
> touch it (up to 75% if you touch the first and the last field, obviously 0%
> if you only touch a single field, but that's unlikely given that you
> usually take a reference then do at least something else like check flags).
> I think the problem with the cache footprint argument is just whether
> it makes any significant difference to performance. But..
The average interval ("run") length is (n+1)/(n-k+1) - 1/C(n,k), so for
that to be >= 8 you need (n+1)/(n-k+1) - 1/C(n,k) >= 8 which also happens
when (n+1)/(n-k+1) >= 9 or when n >= (9/8)*k - 1 or k <= (8/9)*(n+1).
Clearly a lower bound on k is required, but not obviously derivable.
k >= 8 is obvious, but the least k where (n+1)/(n-k+1) - 1/C(n,k) >= 8
is not entirely obvious. Numerically solving for the least such k finds
that k actually needs to be relatively close to (8/9)*n. A lower bound
of something like 0.87*n + O(1) probably holds.
On Mon, May 21, 2007 at 01:08:13AM -0700, William Lee Irwin III wrote:
>> Now that I've been informed of the ->_count and ->_mapcount issues,
>> I'd say that they're grave and should be corrected even at the cost
>> of sizeof(struct page).
On Mon, May 21, 2007 at 11:27:42AM +0200, Nick Piggin wrote:
> ... yeah, something like that would bypass
Did you get cut off here?
-- wli
--
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-21 11:26 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-18 4:08 Nick Piggin
2007-05-18 4:47 ` David Miller, Nick Piggin
2007-05-18 5:12 ` Nick Piggin
2007-05-18 5:22 ` David Miller, Nick Piggin
2007-05-18 5:31 ` Nick Piggin
2007-05-18 18:15 ` Christoph Lameter
2007-05-18 7:19 ` Andrew Morton
2007-05-18 7:32 ` Nick Piggin
2007-05-18 7:43 ` Andrew Morton
2007-05-18 7:59 ` Nick Piggin
2007-05-18 9:42 ` David Howells
2007-05-19 1:30 ` Nick Piggin
2007-05-18 12:06 ` Andi Kleen
2007-05-18 15:42 ` Hugh Dickins
2007-05-19 1:22 ` Nick Piggin
2007-05-19 17:53 ` William Lee Irwin III
2007-05-20 22:50 ` Matthew Wilcox
2007-05-18 18:14 ` Christoph Lameter
2007-05-18 20:37 ` Luck, Tony
2007-05-21 6:28 ` KAMEZAWA Hiroyuki
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 15:43 ` Andy Whitcroft
2007-05-19 18:15 ` [rfc] increase struct page size?! William Lee Irwin III
2007-05-19 18:25 ` Christoph Lameter
2007-05-20 4:10 ` Eric Dumazet
2007-05-20 12:56 ` Andi Kleen
2007-05-21 17:08 ` Christoph Lameter
2007-05-22 0:30 ` KAMEZAWA Hiroyuki
2007-05-22 0:38 ` Christoph Lameter
2007-05-22 0:58 ` KAMEZAWA Hiroyuki
2007-05-22 9:44 ` Geert Uytterhoeven
2007-05-19 22:09 ` Andrew Morton
2007-05-20 7:26 ` William Lee Irwin III
2007-05-21 9:12 ` Helge Hafting
2007-05-21 9:45 ` Nick Piggin
2007-05-20 5:22 ` Nick Piggin
2007-05-20 8:46 ` William Lee Irwin III
2007-05-20 9:25 ` Nick Piggin
2007-05-21 8:08 ` William Lee Irwin III
2007-05-21 9:27 ` Nick Piggin
2007-05-21 11:26 ` William Lee Irwin III [this message]
2007-05-22 0:52 ` Nick Piggin
2007-05-21 22:43 ` Matt Mackall
2007-05-22 1:08 ` Nick Piggin
2007-05-22 1:13 ` Christoph Lameter
2007-05-22 1:39 ` William Lee Irwin III
2007-05-22 1:57 ` Nick Piggin
2007-05-22 5:04 ` William Lee Irwin III
2007-05-22 6:24 ` Nick Piggin
2007-05-22 10:59 ` William Lee Irwin III
2007-05-21 9:31 ` Eric Dumazet
2007-05-21 17:06 ` Christoph Lameter
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=20070521112603.GJ19966@holomorphy.com \
--to=wli@holomorphy.com \
--cc=clameter@sgi.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
/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