Re: [PATCH v2] perf/core: Optimize event reschedule for a PMU

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Aug 02, 2024 at 08:50:23PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 02, 2024 at 08:43:50PM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 02, 2024 at 08:38:41PM +0200, Peter Zijlstra wrote:
> > > On Fri, Aug 02, 2024 at 02:30:19PM -0400, Liang, Kan wrote:
> > > > > @@ -2792,7 +2833,14 @@ static int  __perf_install_in_context(void *info)
> > > > >  	if (reprogram) {
> > > > >  		ctx_sched_out(ctx, EVENT_TIME);
> > 
> > Clearly I should read better...
> > 
> > > > >  		add_event_to_ctx(event, ctx);
> > > > > -		ctx_resched(cpuctx, task_ctx, get_event_type(event));
> > > > > +		if (ctx->nr_events == 1) {
> > > > > +			/* The first event needs to set ctx->is_active. */
> > > > > +			ctx_resched(cpuctx, task_ctx, NULL, get_event_type(event));
> > > > > +		} else {
> > > > > +			ctx_resched(cpuctx, task_ctx, event->pmu_ctx->pmu,
> > > > > +				    get_event_type(event));
> > > > > +			ctx_sched_in(ctx, EVENT_TIME);
> > > > 
> > > > The changelog doesn't mention the time difference much. As my
> > > > understanding, the time is shared among PMUs in the same ctx.
> > > > When perf does ctx_resched(), the time is deducted.
> > > > There is no problem to stop and restart the global time when perf
> > > > re-schedule all PMUs.
> > > > But if only one PMU is re-scheduled while others are still running, it
> > > > may be a problem to stop and restart the global time. Other PMUs will be
> > > > impacted.
> > 
> > So yeah, this stops ctx time but not all PMUs.
> 
> But isn't this already the case? We don't have perf_ctx_disable() here
> currently. 
> 
> Bah, this heat is melting my brain.

I think all it wants is to update time and ensure the added event and
the resched all use the same time, which could be done differently.

But I'll have to continue staring at this later.