lkml.org 
[lkml]   [2013]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 07/12] perf, x86: Avoid checkpointed counters causing excessive TSX aborts v3
From
On Tue, Jan 29, 2013 at 2:00 AM, Andi Kleen <andi@firstfloor.org> wrote:
>
> On Tue, Jan 29, 2013 at 01:30:19AM +0100, Stephane Eranian wrote:
> > >> The counter is reinstated to its state before the critical section but
> > >> the PMI cannot be
> > >> cancelled and there is no state left behind to tell what to do with it.
> > >
> > > The PMI is effectively spurious, but we use it to set back. Don't know
> > > what you mean with "cancel". It already happened of course.
> > >
> > But when you do this, it seems you making INT_CP events unusable
> > for sampling, because you're resetting their value under the cover.
> > So what happens when you sample, especially with a fixed period?
>
> Sampling is forbidden for checkpointed events, the setup code
> enforces that. It's unlikely to be useful anyways.
>
> The main use case for checkpointing is perf stat -T and related
> counting usages.
>
> > >>
> > >> > + if (event->attr.sample_period > 0 &&
> > >> > + event->attr.sample_period < 0x7fffffff)
> > >> > + return -EIO;
> > >> > + }
> > Explain the 0x7fffffff to me? Is that the max period set by default when you
> > just count?
>
> Originally I had just > 0, but then I found that perf stat from the
> guest doesn't work anymore because it sets an very high overflow
> to accumulate counters.
>
> The 0x7fffffff is a somewhat arbitary threshold to detect this case.
>
When I come in with the default frequency mode, then sample_period
is a frequency and not a period anymore. So I could do:

$ perf record -F 100 -e instructions:intx_cp ....

sample_period = 100; freq=1;

That's a very low sampling rate, yet I think it would be rejected by your code.
But I guess in frequency mode, there is no guarantee on the period. The kernel
may lower the period to 1 in an attempt to achieve the desired rate for the tick
period. And that may cause the spurious interrupts.

But if I come in with frequency 0x7fffffff+1, then that's a very high
frequency, thus
small period, I would pass the test. So I think you need to reinforce the test
for freq=1.


\
 
 \ /
  Last update: 2013-01-30 10:21    [W:0.109 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site