>
> On Wed, 22 Feb 2017, Liang, Kan wrote:
>
> > > So from what I understand, the issue is if we have an architecture
> > > with full- width counters and we trigger a x86_perf_event_update()
> > > when bit
> > > 47 is set?
> >
> > No. It related to the counter width. The number of bits we can us
On Wed, 22 Feb 2017, Liang, Kan wrote:
> > So from what I understand, the issue is if we have an architecture with
> > full-
> > width counters and we trigger a x86_perf_event_update() when bit
> > 47 is set?
>
> No. It related to the counter width. The number of bits we can use should be
> 1 bi
> No. It related to the counter width. The number of bits we can use should be
> 1 bit less than the total width. Otherwise, there will be problem.
> For big cores such as haswell, broadwell, skylake, the counter width is 48
> bit.
> So we can only use 47 bits.
> For Silvermont and KNL, the counte
>
> On Mon, 5 Dec 2016, Peter Zijlstra wrote:
>
> > ---
> > Subject: perf,x86: Fix full width counter, counter overflow
> > Date: Tue, 29 Nov 2016 20:33:28 +
> >
> > Lukasz reported that perf stat counters overflow is broken on KNL/SLM.
> >
> > Both these parts have full_width_write set, and
On Mon, 5 Dec 2016, Peter Zijlstra wrote:
> ---
> Subject: perf,x86: Fix full width counter, counter overflow
> Date: Tue, 29 Nov 2016 20:33:28 +
>
> Lukasz reported that perf stat counters overflow is broken on KNL/SLM.
>
> Both these parts have full_width_write set, and that does indeed ha
On Monday, December 5, 2016 11:25 AM, Peter Zijlstra wrote:
> I'll certainly, try. I've queued it as per the below.
Great, thank you!
Lukas
On Fri, Dec 02, 2016 at 12:58:17PM +, Odzioba, Lukasz wrote:
> On Tuesday, November 29, 2016 9:33 PM, Liang, Kan wrote:
> > Yes, the patch as below fixes the issue on my SLM.
>
> It works for me as well.
> Can we still have it in 4.9?
I'll certainly, try. I've queued it as per the below.
--
On Tuesday, November 29, 2016 9:33 PM, Liang, Kan wrote:
> Yes, the patch as below fixes the issue on my SLM.
It works for me as well.
Can we still have it in 4.9?
Thanks,
Lukas
On Tue, Nov 29, 2016 at 12:33 PM, Liang, Kan wrote:
>
>
>> On Tue, Nov 29, 2016 at 07:07:25PM +, Liang, Kan wrote:
>> > > diff --git a/arch/x86/events/intel/core.c
>> > > b/arch/x86/events/intel/core.c index a74a2dbc0180..cb8522290e6a
>> > > 100644
>> > > --- a/arch/x86/events/intel/core.c
>>
> On Tue, Nov 29, 2016 at 07:07:25PM +, Liang, Kan wrote:
> > > diff --git a/arch/x86/events/intel/core.c
> > > b/arch/x86/events/intel/core.c index a74a2dbc0180..cb8522290e6a
> > > 100644
> > > --- a/arch/x86/events/intel/core.c
> > > +++ b/arch/x86/events/intel/core.c
> > > @@ -4034,7 +4034
On Tue, Nov 29, 2016 at 07:07:25PM +, Liang, Kan wrote:
> > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> > index a74a2dbc0180..cb8522290e6a 100644
> > --- a/arch/x86/events/intel/core.c
> > +++ b/arch/x86/events/intel/core.c
> > @@ -4034,7 +4034,7 @@ __init int int
On Tuesday, November 29, 2016 6:20 PM Stephane Eranian wrote:
>> On Tue, Nov 29, 2016 at 1:25 AM, Peter Zijlstra wrote:
>> How can this happen? IIRC the thing increments, we program a negative
>> value, and when it passes 0 we generate a PMI.
>>
> Yeah, that's the part I don't quite unders
> On Tue, Nov 29, 2016 at 09:20:10AM -0800, Stephane Eranian wrote:
> > Max period is limited by the number of bits the kernel can write to an
> MSR.
> > Used to be 31, now it is 47 for core PMU as per patch pointed to by Kan.
>
> No, I think it sets it to 48 now, which is the problem. It should
On Tue, Nov 29, 2016 at 06:30:55PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 29, 2016 at 09:20:10AM -0800, Stephane Eranian wrote:
> > Max period is limited by the number of bits the kernel can write to an MSR.
> > Used to be 31, now it is 47 for core PMU as per patch pointed to by Kan.
>
> No, I
On Tue, Nov 29, 2016 at 9:30 AM, Peter Zijlstra wrote:
> On Tue, Nov 29, 2016 at 09:20:10AM -0800, Stephane Eranian wrote:
>> Max period is limited by the number of bits the kernel can write to an MSR.
>> Used to be 31, now it is 47 for core PMU as per patch pointed to by Kan.
>
> No, I think it s
On Tue, Nov 29, 2016 at 09:20:10AM -0800, Stephane Eranian wrote:
> Max period is limited by the number of bits the kernel can write to an MSR.
> Used to be 31, now it is 47 for core PMU as per patch pointed to by Kan.
No, I think it sets it to 48 now, which is the problem. It should be 1
bit less
On Tue, Nov 29, 2016 at 1:25 AM, Peter Zijlstra wrote:
>
>
> So caveat that I'm ill and cannot think much..
>
> On Mon, Nov 28, 2016 at 11:26:46AM -0800, kan.li...@intel.com wrote:
>
> > Here, all the possible failure cases are listed.
> > Terms:
> > - new: current PMU counter value which read
On Tue, Nov 29, 2016 at 05:06:36PM +, Liang, Kan wrote:
>
>
> > On Tue, Nov 29, 2016 at 02:46:14PM +, Liang, Kan wrote:
> > > > And note that we _ALWAYS_ set the IN bits, even for !sampling events.
> > > > Also note we set max_period to (1<<31) - 1, so we should never
> > > > exceed 31 bi
> On Tue, Nov 29, 2016 at 02:46:14PM +, Liang, Kan wrote:
> > > And note that we _ALWAYS_ set the IN bits, even for !sampling events.
> > > Also note we set max_period to (1<<31) - 1, so we should never
> > > exceed 31 bits.
> > >
> >
> > The max_period is 0xf.
> >
> > The limit is br
On Tue, Nov 29, 2016 at 02:46:14PM +, Liang, Kan wrote:
> > And note that we _ALWAYS_ set the IN bits, even for !sampling events.
> > Also note we set max_period to (1<<31) - 1, so we should never exceed 31
> > bits.
> >
>
> The max_period is 0xf.
>
> The limit is breaked by this pat
> So caveat that I'm ill and cannot think much..
>
> On Mon, Nov 28, 2016 at 11:26:46AM -0800, kan.li...@intel.com wrote:
>
> > Here, all the possible failure cases are listed.
> > Terms:
> > - new: current PMU counter value which read from rdpmcl.
> > - prev: previous counter value whi
So caveat that I'm ill and cannot think much..
On Mon, Nov 28, 2016 at 11:26:46AM -0800, kan.li...@intel.com wrote:
> Here, all the possible failure cases are listed.
> Terms:
> - new: current PMU counter value which read from rdpmcl.
> - prev: previous counter value which is stored in &
> >> > Case B: In PMI. new > prev. delta is positive.
> >> >That's the failure case of Test 3.
> >> >The PMI is triggered by overflow. But there is latency between
> >> >overflow and PMI handler. So new has small amount.
> >> >Current calculation lose the max count value.
> >> >
>
On Mon, Nov 28, 2016 at 11:59 AM, Liang, Kan wrote:
>
>
>> >
>> > Here, all the possible failure cases are listed.
>> > Terms:
>> > - new: current PMU counter value which read from rdpmcl.
>> > - prev: previous counter value which is stored in &hwc->prev_count.
>> > - in PMI/not in PMI
> >
> > Here, all the possible failure cases are listed.
> > Terms:
> > - new: current PMU counter value which read from rdpmcl.
> > - prev: previous counter value which is stored in &hwc->prev_count.
> > - in PMI/not in PMI: the event update happens in PMI handler or not.
> > Current
On Mon, Nov 28, 2016 at 11:26 AM, wrote:
>
> From: Kan Liang
>
> Fixes: ec3232bdf851 ("perf_counter: x86: More accurate counter update")
>
> A bug can be easily reproduced by perf stat loop program on KNL/SLM.
> The loop program is just "for (i=0;i "loops" is set to different value during the tes
From: Kan Liang
Fixes: ec3232bdf851 ("perf_counter: x86: More accurate counter update")
A bug can be easily reproduced by perf stat loop program on KNL/SLM.
The loop program is just "for (i=0;iprev_count.
- in PMI/not in PMI: the event update happens in PMI handler or not.
Current code to ca
27 matches
Mail list logo
