All of
 help / color / mirror / Atom feed
From: Stephane Eranian <>
To: Dave Hansen <>
Cc: LKML <>,
	Peter Zijlstra <>,
	"" <>,,
	"" <>,
	Jiri Olsa <>
Subject: Re: [PATCH] perf: fix interrupt handler timing harness
Date: Mon, 8 Jul 2013 20:08:25 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jul 8, 2013 at 4:34 PM, Dave Hansen <> wrote:
> On 07/04/2013 03:30 PM, Stephane Eranian wrote:
>> There was an misunderstanding on the API of the do_div()
>> macro. It returns the remainder of the division and this
>> was not what the function expected leading to disabling the
>> interrupt latency watchdog.
> "Misunderstanding" is a very kind term for what I did there.  Stephane,
> were you actually running in to the new cpu limit, or were you just
> trying to update kernel.perf_event_max_sample_rate?
I am chasing a problem on HSW desktop where your code triggers the throttling.
It happens systematically on my system first time I run perf record usually the
first time.

I admit I have some issues with your patch and what it is trying to avoid.
There is already interrupt throttling. Your code seems to address latency
issues on the handler rather than rate issues. Yet to mitigate the latency
it is modify the throttling.

For some unknown reasons, my HSW interrupt handler goes crazy for
a while running a very simple:
   $ perf record -e cycles branchy_loop

And I do see in the log:
perf samples too long (2546 > 2500), lowering
kernel.perf_event_max_sample_rate to 50000

Which is an enormous latency. I instrumented the code, and under
normal conditions the latency
of the handler for this perf run, is about 500ns and it is consistent
with what I see on SNB.
However, on HSW, it is sometimes 5x longer. I have no explanation for
this. Andi's patch
to delay the NMI ack is enabled but it does not alleviate this
problem. There is something
else going on possibly with the HW, and I don't know what it is. This
is not a one off. It lasts for
several calls because it fires your watchdog which averages out over
multiple calls.
So one cannot blame this on the case where the samping buffer gets
full, for instance.

My model is:
processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
stepping : 3
microcode : 0x7

So something is not right and I would like to know what it is.
I will keep investigating.

> BTW, I also did the same thing in 2ab00456:
> I'll have a patch out shortly for that one, but its damage would be
> limited to a bogus printk.

  reply	other threads:[~2013-07-08 18:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-04 22:30 Stephane Eranian
2013-07-05  6:54 ` Ingo Molnar
2013-07-05  9:54 ` [tip:perf/urgent] perf: Fix " tip-bot for Stephane Eranian
2013-07-08 14:34 ` [PATCH] perf: fix " Dave Hansen
2013-07-08 18:08   ` Stephane Eranian [this message]
2013-07-08 20:05     ` Dave Hansen
2013-07-08 20:20       ` Stephane Eranian
2013-07-08 20:34         ` Dave Hansen
2013-07-08 20:54           ` Andi Kleen
2013-07-08 20:56             ` Stephane Eranian

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] perf: fix interrupt handler timing harness' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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.