Re: [PATCH RFC v2 0/4] perf: IRQ-bound performance events

[Alexander Gordeev]

On Sun, Jan 05, 2014 at 09:59:49AM -0800, Andi Kleen wrote:
> > This is version 2 of RFC "perf: IRQ-bound performance events". That is an
> > introduction of IRQ-bound performance events - ones that only count in a
> > context of a hardware interrupt handler. Ingo suggested to extend this
> > functionality to softirq and threaded handlers as well:
> 
> Did you measure the overhead in workloads that do a lot of interrupts?
> I assume two WRMSR could be a significant part of the cost of small interrupts.

No, that would be the next step. I hoped first to ensure the way I am
intruding into the current perf design is correct.

> For counting at least it would be likely a lot cheaper to just RDPMC
> and subtract manually.

Sigh, that seems as quite a rework for Intel PMU.

> The cache miss example below is certainly misleading, as cache misses
> by interrupts are often a "debt", that is they are forced on whoever
> is interrupted. I don't think that is a good use of this.

May be useless rather than misleading? :) Actually, cache and power use
are exactly the data I thought are useful if one wants to check the
dependency from the interrupt affinity mask. There was some discussion
on this topic some year ago:

On Mon, May 21, 2012 at 08:36:09AM -0700, Linus Torvalds wrote:
"So it may well make perfect sense to allow a mask of CPU's for
interrupt delivery, but just make sure that the mask all points to
CPU's on the same socket. That would give the hardware some leeway in
choosing the actual core - it's very possible that hardware could
avoid cores that are running with irq's disabled (possibly improving
latecy) or even more likely - avoid cores that are in deeper
powersaving modes."

So this RFC is kind of follow-up to come up with necessary tooling.

> I guess it can be useful for cycles.
> 
> -Andi

Thanks, Andi!

-- 
Regards,
Alexander Gordeev
agordeev@xxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/