Messages in this thread | | | From | Vincent Guittot <> | Date | Wed, 30 Mar 2022 09:30:45 +0200 | Subject | Re: [PATCH 0/6] Add latency_nice priority |
| |
On Mon, 28 Mar 2022 at 18:27, Qais Yousef <qais.yousef@arm.com> wrote: > > On 03/25/22 14:27, Vincent Guittot wrote: > > removed Dhaval's email which returns error > > > > On Thu, 24 Mar 2022 at 18:25, Qais Yousef <qais.yousef@arm.com> wrote: > > > > > > On 03/23/22 16:32, Vincent Guittot wrote: > > > > On Tue, 22 Mar 2022 at 17:39, Qais Yousef <qais.yousef@arm.com> wrote: > > > > > > > > > > Hi Vincent > > > > > > > > > > Thanks for reviving this patchset! > > > > > > > > > > On 03/11/22 17:14, Vincent Guittot wrote: > > > > > > This patchset restarts the work about adding a latency nice priority to > > > > > > describe the latency tolerance of cfs tasks. > > > > > > > > > > > > The patches [1-4] have been done by Parth: > > > > > > https://lore.kernel.org/lkml/20200228090755.22829-1-parth@linux.ibm.com/ > > > > > > > > > > > > I have just rebased and moved the set of latency priority outside the > > > > > > priority update. I have removed the reviewed tag because the patches > > > > > > are 2 years old. > > > > > > > > > > AFAIR the blocking issue we had then is on agreement on the interface. Has this > > > > > been resolved now? I didn't see any further discussion since then. > > > > > > > > I think that there was an agreement about using a latency nice > > > > priority in the range [-20:19] with -20 meaning sensitive to latency > > > > whereas 19 means that task doesn't care about scheduling latency. The > > > > open point was about how to use this input in the scheduler with some > > > > behavior being opposed. > > > > > > What I remember is that the problem was to consolidate on use cases then > > > discuss interfaces. > > > > > > See https://lwn.net/Articles/820659/ > > > > > > " Youssef said that the interface to all of this is the sticking > > > point. Thomas Gleixner agreed, saying that the -20..19 range "requires > > > a crystal ball" to use properly. Zijlstra repeated his call to > > > enumerate the use cases before getting into the interface details. > > > Giani repeated that the interface does not look correct now, and agreed > > > that a more comprehensive look at the use cases was needed. Things were > > > being done backwards currently, he said. " > > > > > > > At LPC, everybody seemed aligned with latency_nice so I assumed that > > there was an agreement on this interface. > > Latency_nice fits well with my proposal because it's all about > > relative comparison between the running task to the others. The > > current nice priority is used to set how much cpu bandwidth a task > > will have compared to others and the latency_nice is used in a similar > > way to know which one should run compared to the others. > > I think the users were happy, but not the maintainers :-) > > I am still happy with it, but I just want to make sure that our use case is > something we still care about having in upstream and we'd still like to use > this interface to achieve that. I don't want it to be blocked based on > interface not suitable. So this should be taken into consideration that this is > not a replacement to at least our previous use case. > > The concept of latency_nice conversion to weight is something new and I don't > think any of the other users requires it. So we need to keep the user visible > interface detached from weight which is internal implementation detail for your > use case.
note that the weight is only another way to describe relative priority but I will keep that in mind for the next version
> > > > > > > > > > > > > > > > > > > > > > > > The patches [5-6] use latency nice priority to decide if a cfs task can > > > > > > preempt the current running task. Patch 5 gives some tests results with > > > > > > cyclictests and hackbench to highlight the benefit of latency nice > > > > > > priority for short interactive task or long intensive tasks. > > > > > > > > > > This is a new use case AFAICT. For Android, we want to do something in EAS path > > > > > > > > I don't think it's new, it's about being able to run some tasks in > > > > > > I meant new use case to latency-nice interface. I don't think we had this in > > > any of our discussions before? I don't mind it, but it'd be good to clarify if > > > it has any relation about the other use cases and what should happen to the > > > other use cases. > > > > Several discussions happened about changing the preemption policy of > > CFS. I have Mel's example in mind with hackbench where we want to > > reduce the preemption capabilities for the threads and on the other > > side the multimedia tasks which complain about having to wait before > > being scheduled. All this is about preempting or not the others. And > > all this has been kept outside topology consideration but only for the > > local run queue > > Cool. I can see its usefulness. Though I still have to convince myself that you > can affect preemption without impacting bandwidth and is not a subtler way to > modify nice.
This has been one of my main goal too: to not modify cpu bandwidth
Thanks Vincent > > > Thanks > > -- > Qais Yousef
| |