lkml.org 
[lkml]   [2009]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 13/15] perf_counter: provide generic callchain bits

* Paul Mackerras <paulus@samba.org> wrote:

> Peter Zijlstra writes:
>
> > Ah, yes, I see how that can confuse. PERF_EVENT_COUNTER_OVERFLOW then?
>
> Sounds reasonable.
>
> > > Also, let's add PERF_RECORD/PERF_EVENT bits for:
> > >
> > > * EVENT_INSTR_ADDR
> >
> > I'm failing to come up with what this could be..
>
> So, you have lots of instructions in flight in the processor, and
> one of them causes an event that increments a counter and causes
> it to overflow, so an interrupt request is generated. Even if the
> interrupt is taken "immediately", it can still happen that the set
> of instructions the processor decides to complete before taking
> the interrupt includes some instructions after the instruction
> that caused the counter to overflow, and of course if interrupts
> are (hard-) disabled at the time of the overflow, the interrupt
> will happen later. That means that the IP from the pt_regs is not
> generally a reliable indication of which instruction made the
> counter overflow.
>
> On POWER processors we have a register which gives us a much more
> reliable indication of which instruction caused the counter
> overflow, at least in those cases where the event can be
> attributed to a specific instruction. This EVENT_INSTR_ADDR bit
> would ask for that register to be sampled and recorded.

So it's a bit like PEBS and IBS on the x86, right?

In theory one could simply override the sampled ptregs->ip with this
more precise register value. The instruction where the IRQ hit is
probably meaningless, if more precise information is available. But
we can have both too i guess.

The data address extension definitely makes sense - it can be used
to for a profile view along the data symbol dimension, instead of
the usual function symbol dimension.

CPU flags makes sense too - irqs-off can help the annotation of
source code sections where the profiler sees that irqs were
disabled.

It seems here we gradually descend into arch-specific CPU state
technicalities and it's not immediately obvious where to draw the
line.

Call-chain and data address abstractions are clear. CPU flags is
less clear: we could perhaps split off the irq state and the
privilege level information - that is present on all CPUs.

The rest should probably be opaque and not generalized.

_Perhaps_, to stem the inevitable list of such small details, it
might make sense to have a record type with signal frame qualities -
which would include most of this info. That would mix well with the
planned feature of signal generation anyway, right?

I.e. we could extend the lowlevel sigcontext signal frame generation
code in arch/x86/kernel/signal.c (and its powerpc equivalent) to
generate a signal frame but output it into the mmap buffer, not into
the userspace stack - and we would not actually execute a signal in
that context.

[ of course, when the counter is configured to generate a signal
that is done too. The code would be dual purpose. ]

So user-space would get a fully signal frame compatible record - and
we'd not have to create a per arch ABI for this because we'd piggy
back to the signal frame format.

We could add SA_NOFPU support for fast-track integer-registers-only
frames, etc.

Hm?

Ingo


\
 
 \ /
  Last update: 2009-04-01 12:03    [W:0.130 / U:0.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site