[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140528145831.GH29957@tassilo.jf.intel.com>
Date: Wed, 28 May 2014 07:58:31 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Yan, Zheng" <zheng.z.yan@...el.com>, linux-kernel@...r.kernel.org,
mingo@...e.hu, eranian@...gle.com
Subject: Re: [RFC PATCH 6/7] perf, x86: large PEBS interrupt threshold
> In particular, the 0x90 offset (IA32_PERF_GLOBAL_STATUS). Intel once
> confirmed to me that that is a direct copy of the similarly named MSR at
> the time of the PEBS assist.
That is correct.
>
> This is a problem, since if multiple counters overflow multiple bits
> will be set and its (afaict) ambiguous which event is for which counter.
When a PEBS counter overflows it clears its respective GLOBAL_STATUS bit
automatically. You may see multiple STATUS bits in the PEBS record
if two PEBS counters overflow at exactly the same time, but that is no different
from the threshold==1 case (and relatively rare)
So the threshold > 1 and the threshold == 1 case work identically.
> So until you can give an official Intel answer on how all this demuxing
> is supposed to work and be correct this patch set isn't moving anywhere.
FWIW a patch signed off by intel.com is an official Intel statement.
>
> > To supply a TID it
> > requires flushing on context switch. It can however supply the IP
>
> On SNB+, previous to SNB it would need to have precise==1. I've seen no
> such logic in. Instead you seem to artificially limit it to SNB+, for no
> apparent reason to me.
Only tested on Sandy Bridge+
-Andi
--
ak@...ux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists