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 01:08:13 -0700 [thread overview]
Message-ID: <20070521080813.GQ31925@holomorphy.com> (raw)
In-Reply-To: <20070520092552.GA7318@wotan.suse.de>
On Sun, May 20, 2007 at 01:46:47AM -0700, William Lee Irwin III wrote:
>> The lack of consideration of the average case. I'll see what I can smoke
>> out there.
On Sun, May 20, 2007 at 11:25:52AM +0200, Nick Piggin wrote:
> 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.
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.
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.
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).
-- wli
Many thanks to int-e on EfNet #math for help with the calculations
(perhaps better described as doing them outright).
Heavily-edited IRC log (using Knuth's conventions for M, N, and k as
the number of runs):
<int-e:#math> wli: oh maybe this can be solved exactly after all. The number
+of configurations of N numbers out of M with exactly k runs is C(N-1, k-1) *
+C(M-N+1, k). When there are k runs, the average run length is N/k, obviously.
<int-e:#math> wli: assume there are k runs. add an empty dummy element at the
+end and at the front - then you have (k+1) empty runs between the k runs.
+Every run has positive length. the empty runs correspond to a partition of
+M-N+2 into k+1 positive numbers, and the occupied runs correspond to one of N
+into k positive numbers, which gives that formula.
<int-e:#math> wli: So the average is 1/C(M,N) * sum[k=1 to N] N/k C(N-1,k-1)
+C(M-N+1,k) = 1/C(M,N) * sum[k=1 to N] C(N,k) C(M-N+1,k) = 1/C(M,N) * (C(M+1,
+N) - 1) = (M+1)/(M-N+1) - 1/C(M,N).
--
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 8:08 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 [this message]
2007-05-21 9:27 ` Nick Piggin
2007-05-21 11:26 ` William Lee Irwin III
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=20070521080813.GQ31925@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