From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Benjamin LaHaise <bcrl@redhat.com>
Cc: Andrew Morton <akpm@digeo.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.5.68-mm2
Date: Thu, 24 Apr 2003 14:13:25 -0700 [thread overview]
Message-ID: <1661460000.1051218805@flay> (raw)
In-Reply-To: <20030423233954.D9036@redhat.com>
>> The performance improvement was about 25% of systime according to my
>> measurements - I don't call that insignificant.
>
> Never, ever use changes in system time as a justification for a patch. We
> all know that Linux's user/system time accounting is patently unreliable.
Mmmm. I'm not particularly convinced by that ... I do 5 runs for every
benchmark and compare the results, and it seems very consistent to me.
For kernbench, it's interesting to look at system time - but obviously
keeping an eye on elapsed time as well, particularly for things like
scheduler patches.
> Remember Nyquist? Talk to me about differences in wall clock and your
> comments will be more interesting.
OK, well then you need to look at something that's not totally dominated
by gcc anyway. I know everyone hates SDET as it's "closed" but I'll try
to rerun with aim7 at some point. A real 20% improvement in throughput
is not to be sniffed at ...
DISCLAIMER: SPEC(tm) and the benchmark name SDET(tm) are registered
trademarks of the Standard Performance Evaluation Corporation. This
benchmarking was performed for research purposes only, and the run results
are non-compliant and not-comparable with any published results.
Results are shown as percentages of the first set displayed
SDET 1 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.7%
2.5.68-objrmap 105.7% 0.4%
SDET 2 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 2.8%
2.5.68-objrmap 108.2% 0.7%
SDET 4 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 1.0%
2.5.68-objrmap 112.0% 1.4%
SDET 8 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.6%
2.5.68-objrmap 122.8% 1.3%
SDET 16 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.1%
2.5.68-objrmap 117.3% 0.8%
SDET 32 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.4%
2.5.68-objrmap 118.5% 0.4%
SDET 64 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.2%
2.5.68-objrmap 121.2% 0.3%
SDET 128 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.1%
2.5.68-objrmap 118.6% 0.2%
WARNING: multiple messages have this Message-ID (diff)
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Benjamin LaHaise <bcrl@redhat.com>
Cc: Andrew Morton <akpm@digeo.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.5.68-mm2
Date: Thu, 24 Apr 2003 14:13:25 -0700 [thread overview]
Message-ID: <1661460000.1051218805@flay> (raw)
In-Reply-To: <20030423233954.D9036@redhat.com>
>> The performance improvement was about 25% of systime according to my
>> measurements - I don't call that insignificant.
>
> Never, ever use changes in system time as a justification for a patch. We
> all know that Linux's user/system time accounting is patently unreliable.
Mmmm. I'm not particularly convinced by that ... I do 5 runs for every
benchmark and compare the results, and it seems very consistent to me.
For kernbench, it's interesting to look at system time - but obviously
keeping an eye on elapsed time as well, particularly for things like
scheduler patches.
> Remember Nyquist? Talk to me about differences in wall clock and your
> comments will be more interesting.
OK, well then you need to look at something that's not totally dominated
by gcc anyway. I know everyone hates SDET as it's "closed" but I'll try
to rerun with aim7 at some point. A real 20% improvement in throughput
is not to be sniffed at ...
DISCLAIMER: SPEC(tm) and the benchmark name SDET(tm) are registered
trademarks of the Standard Performance Evaluation Corporation. This
benchmarking was performed for research purposes only, and the run results
are non-compliant and not-comparable with any published results.
Results are shown as percentages of the first set displayed
SDET 1 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.7%
2.5.68-objrmap 105.7% 0.4%
SDET 2 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 2.8%
2.5.68-objrmap 108.2% 0.7%
SDET 4 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 1.0%
2.5.68-objrmap 112.0% 1.4%
SDET 8 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.6%
2.5.68-objrmap 122.8% 1.3%
SDET 16 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.1%
2.5.68-objrmap 117.3% 0.8%
SDET 32 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.4%
2.5.68-objrmap 118.5% 0.4%
SDET 64 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.2%
2.5.68-objrmap 121.2% 0.3%
SDET 128 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.1%
2.5.68-objrmap 118.6% 0.2%
--
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:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2003-04-24 21:12 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-23 8:20 2.5.68-mm2 Andrew Morton
2003-04-23 8:20 ` 2.5.68-mm2 Andrew Morton
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 16:50 ` 2.5.68-mm2 Robert Love
2003-04-23 16:50 ` 2.5.68-mm2 Robert Love
2003-04-23 16:57 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 16:57 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 17:11 ` 2.5.68-mm2 Robert Love
2003-04-23 17:11 ` 2.5.68-mm2 Robert Love
2003-04-24 9:14 ` 2.5.68-mm2 William Lee Irwin III
2003-04-24 9:14 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 12:08 ` 2.5.68-mm2 Ed Tomlinson
2003-04-23 12:37 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 14:25 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 15:14 ` 2.5.68-mm2 Alex Tomas
2003-04-23 15:14 ` 2.5.68-mm2 Alex Tomas
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
2003-04-23 21:47 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 21:47 ` 2.5.68-mm2 Martin J. Bligh
2003-04-24 3:39 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-24 3:39 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-24 21:13 ` Martin J. Bligh [this message]
2003-04-24 21:13 ` 2.5.68-mm2 Martin J. Bligh
2003-04-24 23:13 ` objrmap (was 2.5.68-mm2) Martin J. Bligh
2003-04-24 23:13 ` Martin J. Bligh
2003-04-24 3:36 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-24 3:36 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-24 20:24 ` 2.5.68-mm2 Bill Davidsen
2003-04-24 20:24 ` 2.5.68-mm2 Bill Davidsen
2003-04-24 20:33 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-24 20:33 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-25 17:56 ` 2.5.68-mm2 Bill Davidsen
2003-04-25 17:56 ` 2.5.68-mm2 Bill Davidsen
2003-04-25 18:20 ` 2.5.68-mm2 Randy.Dunlap
2003-04-25 18:20 ` 2.5.68-mm2 Randy.Dunlap
2003-04-25 18:27 ` 2.5.68-mm2 Robert Love
2003-04-25 18:27 ` 2.5.68-mm2 Robert Love
2003-04-25 18:49 ` 2.5.68-mm2 Martin J. Bligh
2003-04-25 18:49 ` 2.5.68-mm2 Martin J. Bligh
2003-04-26 10:34 ` 2.5.68-mm2 Bill Davidsen
2003-04-26 10:34 ` 2.5.68-mm2 Bill Davidsen
2003-04-26 15:34 ` 2.5.68-mm2 Martin J. Bligh
2003-04-26 15:34 ` 2.5.68-mm2 Martin J. Bligh
2003-05-01 6:19 ` [BUG] 2.5.68-mm2 and list.h Alexander Hoogerhuis
2003-05-01 6:19 ` Alexander Hoogerhuis
2003-05-01 6:31 ` Andrew Morton
2003-05-01 6:31 ` Andrew Morton
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=1661460000.1051218805@flay \
--to=mbligh@aracnet.com \
--cc=akpm@digeo.com \
--cc=bcrl@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.