Re: [PATCH v3 3/5] perf: Allow adding fixed random jitter to the alternate sampling period

[Peter Zijlstra]

On Tue, Mar 11, 2025 at 05:22:16PM +0000, Mark Barnett wrote:

> > @@ -9979,6 +9985,8 @@ static int __perf_event_overflow(struct perf_event *event,
> >   				 int throttle, struct perf_sample_data *data,
> >   				 struct pt_regs *regs)
> >   {
> > +	struct hw_perf_event *hwc = &event->hw;
> > +	u64 sample_period;
> >   	int events = atomic_read(&event->event_limit);
> >   	int ret = 0;
> > @@ -9989,15 +9997,50 @@ static int __perf_event_overflow(struct perf_event *event,
> >   	if (unlikely(!is_sampling_event(event)))
> >   		return 0;
> > -	ret = __perf_event_account_interrupt(event, throttle);
> > +	/*
> > +	 * High Freq samples are injected inside the larger period:
> > +	 *
> > +	 *   |------------|-|------------|-|
> > +	 *   P0          HF P1          HF
> > +	 *
> > +	 * By ignoring the HF samples, we measure the actual period.
> > +	 */
> > +	if (!(hwc->state & PERF_HES_HF_SAMPLE))
> > +		ret = __perf_event_account_interrupt(event, throttle);
> 
> The high-frequency samples should still contribute to interrupt
> accounting/throttling, right? We'd just need to put guards around the
> adaptive period stuff so that HF samples don't contribute to the frequency
> training.

Yeah, I suppose it should. This means breaking up that function but that
isn't hard.