Messages in this thread | | | Date | Wed, 12 Oct 2022 11:46:29 +0200 | From | Juri Lelli <> | Subject | Re: [RFC PATCH 07/11] sched: Add proxy execution |
| |
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
| |