Messages in this thread | | | Subject | Re: [RFC][PATCH] perf_events, x86: PEBS support | From | Peter Zijlstra <> | Date | Wed, 03 Feb 2010 15:40:12 +0100 |
| |
On Wed, 2010-02-03 at 15:30 +0100, Stephane Eranian wrote: > On Wed, Feb 3, 2010 at 3:19 PM, Peter Zijlstra <peterz@infradead.org> wrote: > > On Wed, 2010-02-03 at 15:07 +0100, Stephane Eranian wrote: > >> >> The only improvement that PEBS provides is that you get an IP and the > >> >> machine state at retirement of an instruction that caused the event to > >> >> increment. Thus, the IP points to the next dynamic instruction. The instruction > >> >> is not the one that cause the P-th occurence of the event, if you set the > >> >> period to P. It is at P+N, where N cannot be predicted and varies depending > >> >> on the event and executed code. This introduces some bias in the samples.. > >> > > >> > I'm not sure I follow, it records the next event after overflow, doesn't > >> > that make it P+1? > >> > > >> That is not what I wrote. I did not say if records at P+1. I said it records > >> at P+N, where N varies from sample to sample and cannot be predicted. > >> N is expressed in the unit of the sampling event. > > > > OK, so I'm confused. > > > > The manual says it arms the PEBS assist on overflow, and the PEBS thing > > will then record the next event. Which to me reads like P+1. > > > you are assuming arming is instantaneous.
Yes I was, ok that stinks.
If only they would reset the counter on overflow instead of on record, that would solve quite a few issues I imagine.
Then add IP to the actual instruction and you've got yourself a useful tool :-)
| |