Messages in this thread | | | Date | Wed, 4 Mar 2020 15:18:23 +0000 | From | Qais Yousef <> | Subject | Re: [PATCH v3 1/6] sched/rt: cpupri_find: Implement fallback mechanism for !fit case |
| |
Hi Tao
On 03/04/20 22:51, Tao Zhou wrote:
[...]
> > /** > > * cpupri_find - find the best (lowest-pri) CPU in the system > > * @cp: The cpupri context > > @@ -62,80 +115,72 @@ int cpupri_find(struct cpupri *cp, struct task_struct *p, > > struct cpumask *lowest_mask, > > bool (*fitness_fn)(struct task_struct *p, int cpu)) > > { > > - int idx = 0; > > int task_pri = convert_prio(p->prio); > > + int best_unfit_idx = -1; > > How about using cpumask to store CPUs when the "best unfit" > happened. So, no need to call __cpupri_find() again.
I considered the CPU mask but it's expensive.
I either have to create a percpu variable, or allocate something at every call here. Neither of which seemed acceptable to me.
Recording the idx is simple and cheap IMO.
[...]
> > + /* > > + * If we failed to find a fitting lowest_mask, make sure we fall back > > + * to the last known unfitting lowest_mask. > > + * > > + * Note that the map of the recorded idx might have changed since then, > > + * so we must ensure to do the full dance to make sure that level still > > + * holds a valid lowest_mask. > > + * > > + * As per above, the map could have been concurrently emptied while we > > + * were busy searching for a fitting lowest_mask at the other priority > > + * levels. > > + * > > + * This rule favours honouring priority over fitting the task in the > > + * correct CPU (Capacity Awareness being the only user now). > > + * The idea is that if a higher priority task can run, then it should > > + * run even if this ends up being on unfitting CPU. > > + * > > + * The cost of this trade-off is not entirely clear and will probably > > + * be good for some workloads and bad for others. > > + * > > + * The main idea here is that if some CPUs were overcommitted, we try > > + * to spread which is what the scheduler traditionally did. Sys admins > > + * must do proper RT planning to avoid overloading the system if they > > + * really care. > > + */ > > + if (best_unfit_idx != -1) > > + return __cpupri_find(cp, p, lowest_mask, best_unfit_idx); > > + > > Even use a loop again here, i don't know.
I don't see if going through the loop twice will help here. The proces is racy, and I think by the time we reached here we would have tried hard enough to find the best cpu to run on?
Thanks
-- Qais Yousef
| |