> I just said I want a
> coherent story about what and why we're doing this.
What:
is clear, isn't it? Use this capability which has been long designed
into PEBS, but not used by perf.
Why:
The goal is to go to higher sampling rates with comparable or less overhead.
Higher sampling rates improve
On Mon, Mar 30, 2015 at 10:11:16PM +0200, Andi Kleen wrote:
>
> Fair enough.
>
> For now we can simply only allow multi pebs if only a single
> PEBS event is active (non PEBS events don't matter, as we
> can just ignore those)
>
> This would be always on Atom, which only has a single PEBS
>
Fair enough.
For now we can simply only allow multi pebs if only a single
PEBS event is active (non PEBS events don't matter, as we
can just ignore those)
This would be always on Atom, which only has a single PEBS
counter.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
--
To
On Mon, Mar 30, 2015 at 05:43:45PM +, Liang, Kan wrote:
> As my understanding, Peter means the multiple PEBS bits could be set
> when sampling only one single event.
>
> Peter, could you please clarify?
So the chain of events of a PEBS counter is as follows:
A) the CTRn value reaches 0:
>
> The case you mentioned has already covered in the description.
AFAIK the description was for the "two PEBS events are happening nearby,
so the hardware merges them" case. That is different than what I
described.
Both can happen (very rarely)
> I tried both multiple different events and
ct: Re: [PATCH V5 4/6] perf, x86: handle multiple records in PEBS
> buffer
>
> > > - its possible (and harmless) for the status field to contain set bits
> > >for !PEBS events -- the proposed code is buggy here.
> > I will fix it.
> > > - its p
> > - its possible (and harmless) for the status field to contain set bits
> >for !PEBS events -- the proposed code is buggy here.
> I will fix it.
> > - its possible to have multiple PEBS bits set even though the event
> >really only was for a single event -- if you count everything
> > One corner case needs to mention is that the PEBS hardware doesn't
> > deal well with collisions, when PEBS events happen near to each other.
> > The records for the events can be collapsed into a single one, and
> > it's not possible to reconstruct all events that caused the PEBS
> >
On Mon, Feb 23, 2015 at 09:25:54AM -0500, Kan Liang wrote:
> From: Yan, Zheng
>
> When PEBS interrupt threshold is larger than one, the PEBS buffer
> may include multiple records for each PEBS event. This patch makes
> the code first count how many records each PEBS event has, then
> output the
On Mon, Feb 23, 2015 at 09:25:54AM -0500, Kan Liang wrote:
From: Yan, Zheng zheng.z@intel.com
When PEBS interrupt threshold is larger than one, the PEBS buffer
may include multiple records for each PEBS event. This patch makes
the code first count how many records each PEBS event has,
- its possible (and harmless) for the status field to contain set bits
for !PEBS events -- the proposed code is buggy here.
I will fix it.
- its possible to have multiple PEBS bits set even though the event
really only was for a single event -- if you count everything with
The case you mentioned has already covered in the description.
AFAIK the description was for the two PEBS events are happening nearby,
so the hardware merges them case. That is different than what I
described.
Both can happen (very rarely)
I tried both multiple different events and
One corner case needs to mention is that the PEBS hardware doesn't
deal well with collisions, when PEBS events happen near to each other.
The records for the events can be collapsed into a single one, and
it's not possible to reconstruct all events that caused the PEBS
record, However
, x86: handle multiple records in PEBS
buffer
- its possible (and harmless) for the status field to contain set bits
for !PEBS events -- the proposed code is buggy here.
I will fix it.
- its possible to have multiple PEBS bits set even though the event
really only
Fair enough.
For now we can simply only allow multi pebs if only a single
PEBS event is active (non PEBS events don't matter, as we
can just ignore those)
This would be always on Atom, which only has a single PEBS
counter.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
--
To
On Mon, Mar 30, 2015 at 05:43:45PM +, Liang, Kan wrote:
As my understanding, Peter means the multiple PEBS bits could be set
when sampling only one single event.
Peter, could you please clarify?
So the chain of events of a PEBS counter is as follows:
A) the CTRn value reaches 0:
I just said I want a
coherent story about what and why we're doing this.
What:
is clear, isn't it? Use this capability which has been long designed
into PEBS, but not used by perf.
Why:
The goal is to go to higher sampling rates with comparable or less overhead.
Higher sampling rates improve
On Mon, Mar 30, 2015 at 10:11:16PM +0200, Andi Kleen wrote:
Fair enough.
For now we can simply only allow multi pebs if only a single
PEBS event is active (non PEBS events don't matter, as we
can just ignore those)
This would be always on Atom, which only has a single PEBS
counter.
I
From: Yan, Zheng
When PEBS interrupt threshold is larger than one, the PEBS buffer
may include multiple records for each PEBS event. This patch makes
the code first count how many records each PEBS event has, then
output the samples in batch.
One corner case needs to mention is that the PEBS
From: Yan, Zheng zheng.z@intel.com
When PEBS interrupt threshold is larger than one, the PEBS buffer
may include multiple records for each PEBS event. This patch makes
the code first count how many records each PEBS event has, then
output the samples in batch.
One corner case needs to
20 matches
Mail list logo
