Re: [PATCH v4 0/5] A mechanism for efficient support for per-function metrics

[Ingo Molnar <mingo@kernel.org>]

* Mark Barnett <mark.barnett@arm.com> wrote:

> Tool Integration
> ==================
> 
> We've been using a python script to process the data into a report. We can
> look at implementing this directly in perf report, if that is required.
> However, I'm nervous about making the new feature the default behaviour for
> the tool.

That's OK - but it should be very simple to activate for perf 
record/top. A single option or so to get some sane default behavior, 
without having to micro-manage the period values?

In particular perf defaults to 4000 Hz auto-freq samples (at least on 
my x86 devel box), and it would be nice to make this new feature work 
well with the freq representation too, without complicating it too 
much.

> This feature has been integrated into our tools [1] for the last 12 
> months, and has received a lot of testing on Arm Neoverse hardware. 
> Other platforms have received less rigorous testing. In my opinion, 
> more work would be needed to validate the PMU hardware & software 
> characteristics of other architectures before this can be made the 
> default.

Sure. As long as the switch is simple, I think it will be a popular 
change once the kernel feature goes upstream.

In other words: please add a simple, idiot-proof switch to perf 
top/record for maintainers with chronically short attention spans who 
want to try out your kernel feature. ;)

Please Cc: the perf tooling people to those changes, in general they 
are very open to such features.

> Burst Sampling
> ================
> 
> I like the burst sampling idea. Increased I-Cache pressure is an inherent
> weakness of this sampling method, and this would help to alleviate that
> somewhat. I'll add this in the next spin.

Great, thanks!

> Period Jitter
> ===============
> 
> Yes, we can apply this to both periods. I will make that change.
> 
> I'm not sure I've fully understood your suggestion here. In its 
> current state, the 4-bit jitter field acts as a base-2 exponent. This 
> gives us a random jitter value of up to 2**15. Is the suggestion to 
> change this to a fixed, absolute value that can be applied to both 
> long & short periods?

Oh, I missed the base-2 exponent aspect, I assumed it was a flat period 
in the small integers range, a kind of micro-jitter to counter 
resonance with the finest CPU microarchitectural base-frequencies.

What is the typical useful jitter range in your experience? base-2 
exponents sound a bit too limiting - although the prandom32() indeed 
smears it between [0..2^param). I'd guess that jitter would rarely want 
to be larger than the long-period? (Although that might not always be 
the case.)

I'd generally err on the side of being a bit too generic & generous in 
the design of ABI parameters, because we never know what people will 
use it for ... Within reason that is.

Thanks,

	Ingo