Messages in this thread |  | | From | Vincent Guittot <> | Date | Wed, 23 Mar 2022 16:23:05 +0100 | Subject | Re: [RFC 6/6] sched/fair: Add sched group latency support |
| |
On Tue, 22 Mar 2022 at 17:41, Tim Chen <tim.c.chen@linux.intel.com> wrote: > > On Mon, 2022-03-21 at 07:24 -1000, Tejun Heo 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? > > > > > > The way I was interpreting the latency_nice number is as follow: > Given runnable tasks that have not exceeded their time slice, > the task with the lowest latency nice number run first.
The current version is not such binary in the decision as I wanted to have a smoother level of preemption between close latency nice priority.
> > The current patchset takes care of the > case of tasks within a run queue. I think we also need to > consider which cpu should be selected for a waking > task, if we cannot find an idle CPU. > > It seems reasonable that we wake a task on a CPU that is running a task with > a higher latency nice value and lower load than previous CPU the waking task > has run on. That way we can wake latency sensitive tasks faster in a busy system. > > Tim >
|  |