Re: [RFC PATCH 07/11] sched: Add proxy execution

[Juri Lelli]

On 12/10/22 01:54, Joel Fernandes wrote:

...

> > +migrate_task:
> > +	/*
> > +	 * The blocked-on relation must not cross CPUs, if this happens
> > +	 * migrate @p to the @owner's CPU.
> > +	 *
> > +	 * This is because we must respect the CPU affinity of execution
> > +	 * contexts (@owner) but we can ignore affinity for scheduling
> > +	 * contexts (@p). So we have to move scheduling contexts towards
> > +	 * potential execution contexts.
> > +	 *
> > +	 * XXX [juril] what if @p is not the highest prio task once migrated
> > +	 * to @owner's CPU?
> 
> Then that sounds like the right thing is happening, and @p will not proxy()
> to @owner. Why does @p need to be highest prio?

No, indeed. I (now :) don't think the above is a problem.

> > +	 *
> > +	 * XXX [juril] also, after @p is migrated it is not migrated back once
> > +	 * @owner releases the lock? Isn't this a potential problem w.r.t.
> > +	 * @owner affinity settings?
> 
> Juri, Do you mean here, '@p affinity settings' ?  @p's affinity is being
> ignored right?

Yeah, @p affinity.

> > +	 * [juril] OK. It is migrated back into its affinity mask in
> > +	 * ttwu_remote(), or by using wake_cpu via select_task_rq, guess we
> > +	 * might want to add a comment about that here. :-)
> 
> Good idea!

Connor, maybe you can add such a comment in the next version? Thanks!

> I am also wondering, how much more run-queue lock contention do these
> additional migrations add, that we did not have before. Do we have any data
> on that? Too much migration should not negate benefits of PE hopefully.

Looks like this is a sensible thing to measure.

Best,
Juri