LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Steven Rostedt <srostedt@redhat.com>
Subject: Re: [PATCH 3/3] ftrace: function tracer with irqs disabled
Date: Tue, 4 Nov 2008 09:44:06 -0500 (EST)	[thread overview]
Message-ID: <alpine.DEB.1.10.0811040919060.4140@gandalf.stny.rr.com> (raw)
In-Reply-To: <20081104090405.GA507@elte.hu>


On Tue, 4 Nov 2008, Ingo Molnar wrote:

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > * Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > > Running hackbench 3 times with the irqs disabled and 3 times with 
> > > the preempt disabled function tracer yielded:
> > > 
> > > tracing type       times            entries recorded
> > > ------------      --------          ----------------
> > > irq disabled      43.393            166433066
> > >                   43.282            166172618
> > >                   43.298            166256704
> > > 
> > > preempt disabled  38.969            159871710
> > >                   38.943            159972935
> > >                   39.325            161056510
> > 
> > your numbers might be correct, but i found that hackbench is not 
> > reliable boot-to-boot - it can easily produce 10% systematic noise 
> > or more. (perhaps depending on how the various socket data 
> > structures happen to be allocated)
> > 
> > the really conclusive way to test this would be to add a hack that 
> > either does preempt disable or irqs disable, depending on a runtime 
> > flag - and then observe how hackbench performance reacts to the 
> > value of that flag.
> 
> ... which is exactly what your patch implements :-)

Yep ;-)

Those numbers were done without any reboots in between. I even tried it
several times, randomly picking to use irqs_disabled and preempt_disabled,
and everytime preempt_disabled was around 39 secs, and irqs disabled was
around 43.

> 
> > note that preempt-disable will also produce less trace entries, 
> > especially in very irq-rich workloads. Hence it will be "faster".
> 
> this point still holds. Do we have any good guess about the 'captured 
> trace events per second' rate in the two cases, are they the same?

If you look at the end of my change log, I printed stats from a patch I 
added that counted the times that ftrace recursed, but did not record.
Those numbers were quite big with preempt_disabled.

>> With irq disabled: 1,150 times the function tracer did not trace due to
>>   recursion.
>> with preempt disabled: 5,117,718 times.

When we used the preempt disabled version, we lost 5 million traces, as 
suppose to the irq disabled which was only 1,150 traces lost.

Considering that we had 166,256,704 traces total, that 5 million is only 
4% lost of traces. Still quite a lot. But again, this is an extreme,
because we are tracing hackbench.

-- Steve


  reply	other threads:[~2008-11-04 14:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-04  4:15 [PATCH 0/3] ftrace: code consolidation Steven Rostedt
2008-11-04  4:15 ` [PATCH 1/3] ftrace: ftrace_preempt_disable Steven Rostedt
2008-11-04  9:10   ` Ingo Molnar
2008-11-04 21:48     ` [PATCH] ftrace: ftrace_preempt_disable comment fix Steven Rostedt
2008-11-04 21:52       ` [PATCH v2] " Steven Rostedt
2008-11-04 22:05         ` [PATCH v3] " Steven Rostedt
2008-11-04  4:15 ` [PATCH 2/3] ftrace: insert in the ftrace_preempt_disable functions Steven Rostedt
2008-11-04  4:15 ` [PATCH 3/3] ftrace: function tracer with irqs disabled Steven Rostedt
2008-11-04  8:07   ` Ingo Molnar
2008-11-04  8:17     ` Zhang, Yanmin
2008-11-04  9:04     ` Ingo Molnar
2008-11-04 14:44       ` Steven Rostedt [this message]
2008-11-04 16:43         ` Ingo Molnar

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=alpine.DEB.1.10.0811040919060.4140@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=srostedt@redhat.com \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH 3/3] ftrace: function tracer with irqs disabled' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).