From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
Cc: linux-kernel@vger.kernel.org,
btrace <linux-btrace@vger.kernel.org>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: Linux Kernel Markers - performance characterization with large IO load on large-ish system
Date: Tue, 25 Sep 2007 17:13:49 +0000 [thread overview]
Message-ID: <20070925171349.GA6057@Krystal> (raw)
In-Reply-To: <46F92219.9020406@hp.com>
* Alan D. Brunelle (Alan.Brunelle@hp.com) wrote:
> Taking Linux 2.6.23-rc6 + 2.6.23-rc6-mm1 as a basis, I took some sample
> runs of the following on both it and after applying Mathieu Desnoyers
> 11-patch sequence (19 September 2007).
>
> * 32-way IA64 + 132GiB + 10 FC adapters + 10 HP MSA 1000s (one 72GiB
> volume per MSA used)
>
> * 10 runs with each configuration, averages shown below
> o 2.6.23-rc6 + 2.6.23-rc6-mm1 without blktrace running
> o 2.6.23-rc6 + 2.6.23-rc6-mm1 with blktrace running
> o 2.6.23-rc6 + 2.6.23-rc6-mm1 + markers without blktrace running
> o 2.6.23-rc6 + 2.6.23-rc6-mm1 + markers with blktrace running
>
> * A run consists of doing the following in parallel:
> o Make an ext3 FS on each of the 10 volumes
> o Mount & unmount each volume
> + The unmounting generates a tremendous amount of writes
> to the disks - thus stressing the intended storage
> devices (10 volumes) plus the separate volume for all
> the blktrace data (when blk tracing is enabled).
> + Note the times reported below only cover the
> make/mount/unmount time - the actual blktrace runs
> extended beyond the times measured (took quite a while
> for the blk trace data to be output). We're only
> concerned with the impact on the "application"
> performance in this instance.
>
> Results are:
>
> Kernel w/out BT STDDEV w/ BT STDDEV
> ------------------------------------- --------- ------ --------- ------
> 2.6.23-rc6 + 2.6.23-rc6-mm1 14.679982 0.34 27.754796 2.09
> 2.6.23-rc6 + 2.6.23-rc6-mm1 + markers 14.993041 0.59 26.694993 3.23
>
Interesting results, although we cannot say any of the solutions has much
impact due to the std dev.
Also, it could be interesting to add the "blktrace compiled out" as a
base line.
Thanks for running those tests,
Mathieu
> It looks to be about 2.1% increase in time to do the make/mount/unmount
> operations with the marker patches in place and no blktrace operations.
> With the blktrace operations in place we see about a 3.8% decrease in
> time to do the same ops.
>
> When our Oracle benchmarking machine frees up, and when the
> marker/blktrace patches are more stable, we'll try to get some "real"
> Oracle benchmark runs done to gage the impact of the markers changes to
> performance...
>
> Alan D. Brunelle
> Hewlett-Packard / Open Source and Linux Organization / Scalability and
> Performance Group
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
Cc: linux-kernel@vger.kernel.org,
btrace <linux-btrace@vger.kernel.org>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: Linux Kernel Markers - performance characterization with large IO load on large-ish system
Date: Tue, 25 Sep 2007 13:13:49 -0400 [thread overview]
Message-ID: <20070925171349.GA6057@Krystal> (raw)
In-Reply-To: <46F92219.9020406@hp.com>
* Alan D. Brunelle (Alan.Brunelle@hp.com) wrote:
> Taking Linux 2.6.23-rc6 + 2.6.23-rc6-mm1 as a basis, I took some sample
> runs of the following on both it and after applying Mathieu Desnoyers
> 11-patch sequence (19 September 2007).
>
> * 32-way IA64 + 132GiB + 10 FC adapters + 10 HP MSA 1000s (one 72GiB
> volume per MSA used)
>
> * 10 runs with each configuration, averages shown below
> o 2.6.23-rc6 + 2.6.23-rc6-mm1 without blktrace running
> o 2.6.23-rc6 + 2.6.23-rc6-mm1 with blktrace running
> o 2.6.23-rc6 + 2.6.23-rc6-mm1 + markers without blktrace running
> o 2.6.23-rc6 + 2.6.23-rc6-mm1 + markers with blktrace running
>
> * A run consists of doing the following in parallel:
> o Make an ext3 FS on each of the 10 volumes
> o Mount & unmount each volume
> + The unmounting generates a tremendous amount of writes
> to the disks - thus stressing the intended storage
> devices (10 volumes) plus the separate volume for all
> the blktrace data (when blk tracing is enabled).
> + Note the times reported below only cover the
> make/mount/unmount time - the actual blktrace runs
> extended beyond the times measured (took quite a while
> for the blk trace data to be output). We're only
> concerned with the impact on the "application"
> performance in this instance.
>
> Results are:
>
> Kernel w/out BT STDDEV w/ BT STDDEV
> ------------------------------------- --------- ------ --------- ------
> 2.6.23-rc6 + 2.6.23-rc6-mm1 14.679982 0.34 27.754796 2.09
> 2.6.23-rc6 + 2.6.23-rc6-mm1 + markers 14.993041 0.59 26.694993 3.23
>
Interesting results, although we cannot say any of the solutions has much
impact due to the std dev.
Also, it could be interesting to add the "blktrace compiled out" as a
base line.
Thanks for running those tests,
Mathieu
> It looks to be about 2.1% increase in time to do the make/mount/unmount
> operations with the marker patches in place and no blktrace operations.
> With the blktrace operations in place we see about a 3.8% decrease in
> time to do the same ops.
>
> When our Oracle benchmarking machine frees up, and when the
> marker/blktrace patches are more stable, we'll try to get some "real"
> Oracle benchmark runs done to gage the impact of the markers changes to
> performance...
>
> Alan D. Brunelle
> Hewlett-Packard / Open Source and Linux Organization / Scalability and
> Performance Group
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2007-09-25 17:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-25 14:58 Linux Kernel Markers - performance characterization with large Alan D. Brunelle
2007-09-25 14:58 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Alan D. Brunelle
2007-09-25 17:13 ` Mathieu Desnoyers [this message]
2007-09-25 17:13 ` Mathieu Desnoyers
2007-09-26 15:28 ` Linux Kernel Markers - performance characterization with large Alan D. Brunelle
2007-09-26 15:28 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Alan D. Brunelle
2007-10-02 12:21 ` Linux Kernel Markers - performance characterization with large Jens Axboe
2007-10-02 12:21 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Jens Axboe
2007-10-02 12:48 ` Mathieu Desnoyers
2007-10-02 12:48 ` Mathieu Desnoyers
2007-10-02 17:51 ` Linux Kernel Markers - performance characterization with large Alan D. Brunelle
2007-10-02 17:51 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Alan D. Brunelle
2007-10-07 19:32 ` Linux Kernel Markers - performance characterization with large Ingo Molnar
2007-10-07 19:32 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Ingo Molnar
2007-10-07 22:10 ` Linux Kernel Markers - performance characterization with large Joshua Root
2007-10-07 22:10 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Joshua Root
2007-10-09 17:31 ` Mathieu Desnoyers
2007-10-09 17:31 ` Mathieu Desnoyers
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=20070925171349.GA6057@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=Alan.Brunelle@hp.com \
--cc=jens.axboe@oracle.com \
--cc=linux-btrace@vger.kernel.org \
--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.