Message-ID: <20090401100015.GD27865@elte.hu>
Date:	Wed, 1 Apr 2009 12:00:15 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 13/15] perf_counter: provide generic callchain bits


* Paul Mackerras <paulus@...ba.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists