All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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.