From: William Lee Irwin III <wli@holomorphy.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] i386: Remove page sized slabs for pgds and pmds
Date: Wed, 28 Mar 2007 15:37:53 -0700 [thread overview]
Message-ID: <20070328223753.GZ8915@holomorphy.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0703281418040.13870@schroedinger.engr.sgi.com>
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
>> I already went over the methodological issues with kernel compiles.
>> You may be able to prove this, but not this way.
On Wed, Mar 28, 2007 at 02:20:20PM -0700, Christoph Lameter wrote:
> But this way is an established kernel way of doing things. Seems that my
> AIM9 stuff was not convincing and I am not sure what other tests would be
> acceptable. Could you post some of data regarding the improvements
> possible through your patches?
What I did, I did a number of years ago. Even if I could find the
results (and I don't even recall order-of-magnitude estimates) they
would be effectively irrelevant to modern kernels. The disaster in
all this was that the PTE caching never got merged. It's not much of
an observation to note that the primarily bottleneck is still there
when the patch to resolve it never got merged.
As far as kernel compiles being relevant to anything besides
potentially optimizing a particular major benchmark using gcc as one
of its components... yeah, right. It's too macro to be a microbenchmark
of anything and too micro to be pertinent to any meaningful
macrobenchmark such as those from major benchmark publishers (who can't
be named for trademark/etc. reasons). Hasn't it been at least 5 years
since people figured out kernel compiles were complete bulls**t as
benchmarks along with dbench for other reasons and several others? If
not, I don't know why I bother with this kernel at all.
Even so, I already did this and am done with it. It's not like I'm
not carrying around numerous patches I know will never be merged all
the time anyway. If you want to back it all out so badly, just do it
and stop bothering me about it, and I'll merely continue maintaining my
local patches without ever posting them as I have been for years. I'm
not at all happy with the NIH situation, either, not that I'm at such a
loss for ideas to need to contest every petty NIH that flies past.
-- wli
next prev parent reply other threads:[~2007-03-28 22:37 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-28 20:12 [RFC] i386: Remove page sized slabs for pgds and pmds Christoph Lameter
2007-03-28 20:45 ` Andrew Morton
2007-03-28 21:05 ` Christoph Lameter
2007-03-28 21:16 ` William Lee Irwin III
2007-03-28 21:20 ` Christoph Lameter
2007-03-28 22:37 ` William Lee Irwin III [this message]
2007-03-28 23:44 ` Christoph Lameter
2007-03-29 0:53 ` William Lee Irwin III
2007-03-29 1:09 ` Christoph Lameter
2007-03-29 1:17 ` Benjamin LaHaise
2007-03-28 20:50 ` William Lee Irwin III
2007-03-28 21:00 ` Christoph Lameter
2007-03-28 21:24 ` William Lee Irwin III
2007-03-28 21:38 ` Christoph Lameter
2007-03-28 22:01 ` William Lee Irwin III
2007-03-28 22:22 ` Christoph Lameter
2007-03-29 0:28 ` Alan Cox
2007-03-29 0:59 ` William Lee Irwin III
2007-03-28 22:26 ` Chris Wright
2007-03-28 22:33 ` William Lee Irwin III
2007-03-28 22:45 ` Chris Wright
2007-03-28 23:42 ` Zachary Amsden
2007-03-28 22:47 ` Chris Wright
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=20070328223753.GZ8915@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.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 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.