public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Suresh E. Warrier" <warrier@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH] ring-buffer: More precise time stamps for nested writes
Date: Fri, 27 Mar 2015 00:38:43 -0500	[thread overview]
Message-ID: <5514ECE3.6030200@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150324191928.18b9f9f2@gandalf.local.home>


On 03/24/2015 06:19 PM, Steven Rostedt wrote:
> On Tue, 24 Mar 2015 18:10:05 -0500
> 
..
..
> There is no architecture where disabling interrupts is cheap. Actually,
> enabling them is the killer. Doing function tracing shows the impact of
> this rather well, as it would disable and enable interrupts for every
> function call, which can get rather expensive in the sum of things, and
> it does skew the timings and can make it more difficult to debug
> heissenbugs.
>

On PPC64, enabling and disabling soft IRQs is simply a matter of 
setting/clearing a per-CPU global variable (in the per-CPU PACA
structure), so it shouldn't be expensive unless an interrupt is
pending when we re-enable, which should be rare. I ran a series of 
tests on a Power8 box and even with a cold cache, both the 
local_irq_save and  local_irq_restore routines only took a few 
nanoseconds, although the restore was a little more expensive 
than the save. (The restore took about 80-160 ns on a cold cache 
and 20-30 ns on a warm one.)

> That said, I feel your pain. I've had some ideas about doing this
> without disabling interrupts. 

That is excellent! 

> But for now, what can be done is to have
> a flag that is set that will implement this or not. Using
> static_branch() to implement it such that when its off it has no effect.
> 

Are you recommending that for now I use a static_branch() instead
of a CONFIG option to fix this? I could do that but the resulting 
code will either be messier to read (with several if condition checks)
or will require some duplication of code. My assumption is that the
new CONFIG option when disabled should have negligible impact since
the compiler inlines the functions.

-suresh

> In the mean time, I can go and revisit trying to have better timings
> with nested writes.
> 
> -- Steve
> 


  reply	other threads:[~2015-03-27  5:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1426827724-22200-1-git-send-email-warrier@linux.vnet.ibm.com>
2015-03-24 23:10 ` [PATCH] ring-buffer: More precise time stamps for nested writes Suresh E. Warrier
2015-03-24 23:19   ` Steven Rostedt
2015-03-27  5:38     ` Suresh E. Warrier [this message]
2015-03-27 16:04       ` Steven Rostedt
2015-03-27 22:14         ` Paul Mackerras
2015-03-27 22:17           ` Steven Rostedt

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=5514ECE3.6030200@linux.vnet.ibm.com \
    --to=warrier@linux.vnet.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox