On 03/05/21 15:41, Valentin Schneider wrote: > On 05/03/21 15:56, Peter Zijlstra wrote: > > On Sat, Dec 26, 2020 at 01:54:45PM +0000, Qais Yousef wrote: > >> > >> > +static inline struct task_struct *get_push_task(struct rq *rq) > >> > +{ > >> > + struct task_struct *p = rq->curr; > >> > >> Shouldn't we verify the class of the task here? The RT task in migration > >> disabled could have been preempted by a dl or stopper task. Similarly, the > >> dl > >> task could have been preempted by a stopper task. > >> > >> I don't think an RT task should be allowed to push a dl task under any > >> circumstances? > > > > Hmm, quite. Fancy doing a patch? > > Last time we talked about this, I looked into > > push_rt_task() + find_lowest_rq() > > IIRC, with how > > find_lowest_rq() + cpupri_find_fitness() > > currently work, find_lowest_rq() should return -1 in push_rt_task() if > rq->curr is DL (CPUPRI_INVALID). IOW, Migration-Disabled RT tasks shouldn't
[...] > If you look closely, this is exactly the same as the previous spread > modulo CPU numbers. IOW, this is (again) a CPU renumbering exercise. I don't see it a re-numbering exercise. The way I understand it a system designer doesn't expect their DL task to move because of an RT task. I think we should try to keep it this way, that's why I asked. To be fair, I need to look at the code again and understand where I missed that 3rd condition Peter mentioned. Thanks -- Qais Yousef