Re: [PATCH] perf_counter: Add alignment-faults and emulation-faults sw events

[Anton Blanchard <anton@samba.org>]

 
Hi Ingo,

> Looks useful.
> 
> I'm wondering about the enumeration space: in other cases when some 
> simple event was further refined we went to add a new perf_type_id 
> and a separate enumeration space, with no limits to extensibility. 
> We'd have a new 'enum perf_sw_fault_id' space.
> 
> Page faults are special anyway, because they carry a 'data' 
> (faulting address) sample as well.
> 
> So i'm wondering how a good, generic enumeration of all things page 
> faults would look like. If we extend perf_sw_ids linearly we might 
> lose some structure.
> 
> For example major versus minor might be a dimension (bit) in the 
> enumeration space, so we'd have:
> 
>    { major | minor } x { native, unaligned, emulated }
> 
> This provides an advantage already: the current 'all' page faults 
> counter would become the 'major|minor' case in the new enumeration.
> 
> We could still keep around the old events as well for some time, but 
> the tools would use the new enumeration.

My initial feeling is that emulation and alignment faults shouldn't
roll up into page faults, because that may cause cause someone to think the
problem is something to do with translation. I don't have a strong opinion
on it however :)

Since we are talking about SW events, I thought I'd bring up some ideas
I was discussing with Paul the other day. The hardware guys like to build
CPI stacks, basically breaking down the CPI into its components (CPI due
to TLB misses, CPI due to dcache misses etc). This offers a great
high level view of what needs to be fixed in order to improve performance.

Taking a step back, it would be great if we could have enough SW
events and counters to be able to do this at the kernel level. A few
events/counters that come to mind are cputime lost due to swap, IO
initiated by the process, interrupts and other processes being scheduled.
I wonder if the delay accounting code has anything we can reuse for this.

With these events we could simply run perf stat and instantly see what
needs fixing at both the cpu level (via CPI analysis) and at the kernel
level (via SW counters).

Anton