From: Ingo Molnar <mingo@elte.hu>
To: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
linux-kernel@vger.kernel.org,
btrace <linux-btrace@vger.kernel.org>,
Jens Axboe <jens.axboe@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Linux Kernel Markers - performance characterization with large
Date: Sun, 07 Oct 2007 19:32:56 +0000 [thread overview]
Message-ID: <20071007193256.GA18558@elte.hu> (raw)
In-Reply-To: <46FA7A86.6090804@hp.com>
* Alan D. Brunelle <Alan.Brunelle@hp.com> wrote:
> o All kernels start off with Linux 2.6.23-rc6 + 2.6.23-rc6-mm1
>
> o '- bt cfg' or '+ bt cfg' means a kernel without or with blktrace
> configured respectively.
>
> o '- markers' or '+ markers' means a kernel without or with the
> 11-patch marker series respectively.
>
> 38 runs without blk traces being captured (dropped hi/lo value from 40 runs)
>
> Kernel Options Min val Avg val Max val Std Dev
> ------------------ --------- --------- --------- ---------
> - markers - bt cfg 15.349127 16.169459 16.372980 0.184417
> + markers - bt cfg 15.280382 16.202398 16.409257 0.191861
>
> - markers + bt cfg 14.464366 14.754347 16.052306 0.463665
> + markers + bt cfg 14.421765 14.644406 15.690871 0.233885
actually, the pure marker overhead seems to be a regression:
> - markers - bt cfg 15.349127 16.169459 16.372980 0.184417
> + markers - bt cfg 15.280382 16.202398 16.409257 0.191861
why isnt the marker near zero-cost as it should be? (as long as they are
enabled but are not in actual use) 2% increase is _ALOT_. That's the
whole point of good probes: they do not slow down the normal kernel.
_Worst case_ it should be at most a few instructions overhead but that
does not explain the ~2% wall-clock time regression you measured here.
So there's something wrong going on - either markers have unacceptably
high cost, or the measurement is not valid.
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
linux-kernel@vger.kernel.org,
btrace <linux-btrace@vger.kernel.org>,
Jens Axboe <jens.axboe@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Linux Kernel Markers - performance characterization with large IO load on large-ish system
Date: Sun, 7 Oct 2007 21:32:56 +0200 [thread overview]
Message-ID: <20071007193256.GA18558@elte.hu> (raw)
In-Reply-To: <46FA7A86.6090804@hp.com>
* Alan D. Brunelle <Alan.Brunelle@hp.com> wrote:
> o All kernels start off with Linux 2.6.23-rc6 + 2.6.23-rc6-mm1
>
> o '- bt cfg' or '+ bt cfg' means a kernel without or with blktrace
> configured respectively.
>
> o '- markers' or '+ markers' means a kernel without or with the
> 11-patch marker series respectively.
>
> 38 runs without blk traces being captured (dropped hi/lo value from 40 runs)
>
> Kernel Options Min val Avg val Max val Std Dev
> ------------------ --------- --------- --------- ---------
> - markers - bt cfg 15.349127 16.169459 16.372980 0.184417
> + markers - bt cfg 15.280382 16.202398 16.409257 0.191861
>
> - markers + bt cfg 14.464366 14.754347 16.052306 0.463665
> + markers + bt cfg 14.421765 14.644406 15.690871 0.233885
actually, the pure marker overhead seems to be a regression:
> - markers - bt cfg 15.349127 16.169459 16.372980 0.184417
> + markers - bt cfg 15.280382 16.202398 16.409257 0.191861
why isnt the marker near zero-cost as it should be? (as long as they are
enabled but are not in actual use) 2% increase is _ALOT_. That's the
whole point of good probes: they do not slow down the normal kernel.
_Worst case_ it should be at most a few instructions overhead but that
does not explain the ~2% wall-clock time regression you measured here.
So there's something wrong going on - either markers have unacceptably
high cost, or the measurement is not valid.
Ingo
next prev parent reply other threads:[~2007-10-07 19:32 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
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 ` Ingo Molnar [this message]
2007-10-07 19:32 ` 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=20071007193256.GA18558@elte.hu \
--to=mingo@elte.hu \
--cc=Alan.Brunelle@hp.com \
--cc=akpm@linux-foundation.org \
--cc=jens.axboe@oracle.com \
--cc=linux-btrace@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
/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.