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

  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.