Messages in this thread |  | | From | Vincent Guittot <> | Date | Tue, 22 Mar 2022 17:10:36 +0100 | Subject | Re: [RFC 6/6] sched/fair: Add sched group latency support |
| |
Hi Tejun,
On Mon, 21 Mar 2022 at 18:24, Tejun Heo <tj@kernel.org> wrote: > > Hello, > > On Fri, Mar 11, 2022 at 05:14:06PM +0100, Vincent Guittot wrote: > > Tasks can set its latency priority which is then used to decide to preempt > > the current running entity of the cfs but sched group entities still have > > the default latency priority. > > > > Add a latency field in task group to set the latency priority of the group > > which will be used against other entity in the parent cfs. > > One thing that bothers me about this interface is that the configuration > values aren't well defined. We have the same problems with the nice levels > but at least have them map to well defined weight values, which likely won't > change in any foreseeable future. The fact that we have the > not-too-well-defined nice levels as an interface shouldn't be a reason we > add another one. Provided that this is something scheduler folks want, it'd > be really great if the interface can be better thought through. What are the > numbers actually encoding?
latency_nice is quite similar to nice. The nice latency is used as an index to get a latency weight in the range [-1024:1024]. latency_nice is in the range [-20:19] and latency_prio shifts it in the range [0:40] . This index is then used to get the latency weight similar to how the nice prio is used to get a weight. That being said, the latency should probably reflect the latency_weight instead of the latency_prio in order to be aligned with the weight and weight.nice fields of cgroups.
As described in patch 5 commit message, the weight is then used to compute a relative offset to check whether the waking task can preempt the current running task.
Vincent
> > Thanks. > > -- > tejun
|  |