Messages in this thread |  | | From | Chen Yu <> | Date | Wed, 4 May 2022 19:14:52 +0800 | Subject | Re: [RFC 5/6] sched/fair: Take into account latency nice at wakeup |
| |
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?
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; > +} > +
|  |