Messages in this thread | | | From | Vincent Guittot <> | Date | Thu, 22 Sep 2022 09:19:26 +0200 | Subject | Re: [PATCH v4 0/8] Add latency priority for CFS class |
| |
On Wed, 21 Sept 2022 at 18:08, Qais Yousef <qais.yousef@arm.com> wrote: > > Hi Vincent > > On 09/16/22 10:02, Vincent Guittot wrote: > > This patchset restarts the work about adding a latency 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. > > > > The patch [5] uses latency nice priority to define a latency offset > > and then to decide if a cfs task can preempt the current running task. The > > patch gives some tests results with cyclictests and hackbench to highlight > > the benefit of latency priority for short interactive task or > > long intensive tasks. > > > > Patch [6] adds the support of latency_offset to task group by adding a > > cpu.latency field. There were discussions for the last version about > > using a real unit for the field so I decided to expose directly the > > latency offset which reflects the time up to which we can preempt when the > > value is negative, or up to which we can defer the preemption when the > > value is positive. > > The range is [-sysctl_sched_latency:sysctl_sched_latency] > > > > Patch [7] makes sched_core taking into account the latency offset. > > > > Patch [8] adds a rb tree to cover some corner cases where the latency > > sensitive task is preempted by high priority task (RT/DL) or fails to > > preempt them. This patch ensures that tasks will have at least a > > slice of sched_min_granularity in priority at wakeup. The patch gives > > results to show the benefit in addition to patch 5 > > > > I have also backported the patchset on a dragonboard RB3 with an android > > mainline kernel based on v5.18 for a quick test. I have used > > the TouchLatency app which is part of AOSP and described to be very good > > test to highlight jitter and jank frame sources of a system [1]. > > In addition to the app, I have added some short running tasks waking-up > > regularly (to use the 8 cpus for 4 ms every 37777us) to stress the system > > without overloading it (and disabling EAS). The 1st results shows that the > > patchset helps to reduce the missed deadline frames from 5% to less than > > 0.1% when the cpu.latency of task group are set. > > > > [1] https://source.android.com/docs/core/debug/eval_perf#touchlatency > > One thing that still confuses me is whether this proposal is supposed to be the > only consumer of this interface or we still expect other users to be able to > use this hint to optimize other sources of latency in the scheduler? Last > discussion [1] raised issues on the interface and I haven't seen any > discussions on the suitability of the interface to enable future consumers. > > I might have missed something. What's the current state on this?
Nothing has changed since the discussion in March: https://lore.kernel.org/lkml/CAKfTPtBCKyqa-472Z7LtiWTq+Yirq6=jSrkzJtNbkdKXnwP-mA@mail.gmail.com/T/
> > > [1] https://lwn.net/Articles/820659/ > > > Thanks > > -- > Qais Yousef
| |