lkml.org 
[lkml]   [2020]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2020-03-04 16:19    [W:0.092 / U:1.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site