Messages in this thread |  | | From | Vincent Guittot <> | Date | Wed, 4 May 2022 14:39:10 +0200 | Subject | Re: [RFC 5/6] sched/fair: Take into account latency nice at wakeup |
| |
On Wed, 4 May 2022 at 13:15, Chen Yu <yu.chen.surf@gmail.com> wrote: > > On Sat, Mar 12, 2022 at 7:11 AM Vincent Guittot > <vincent.guittot@linaro.org> wrote: > > > > Take into account the nice latency priority of a thread when deciding to > > preempt the current running thread. We don't want to provide more CPU > > bandwidth to a thread but reorder the scheduling to run latency sensitive > > task first whenever possible. > > > ---------->8------------------- > > #endif /* CONFIG_SMP */ > > > > +static long wakeup_latency_gran(int latency_weight) > > +{ > > + long thresh = sysctl_sched_latency; > If I understood correctly, this is to consider the latency weight and > 'shrink/expand' > current task's time slice thus to facilitate preemption. And may I > know why don't we use > __sched_period() but to use sysctl_sched_latency directly? Is it > possible the rq has > more than 8(sched_nr_latency) tasks thus the period is longer than > sysctl_sched_latency?
Main reason is to be aligned with place_entity which also uses sysctl_sched_latency to cap entity's vruntime to be higher than min_vruntime-sysctl_sched_latency
> > Thanks, > Chenyu > > + > > + if (!latency_weight) > > + return 0; > > + > > + if (sched_feat(GENTLE_FAIR_SLEEPERS)) > > + thresh >>= 1; > > + > > + /* > > + * Clamp the delta to stay in the scheduler period range > > + * [-sysctl_sched_latency:sysctl_sched_latency] > > + */ > > + latency_weight = clamp_t(long, latency_weight, > > + -1 * NICE_LATENCY_WEIGHT_MAX, > > + NICE_LATENCY_WEIGHT_MAX); > > + > > + return (thresh * latency_weight) >> NICE_LATENCY_SHIFT; > > +} > > +
|  |