This is a backport of the series that fixes the way deadline bandwidth
restoration is done which is causing noticeable delay on resume path. It also
converts the cpuset lock back into a mutex which some users on Android too.
I lack the details but AFAIU the read/write semaphore was slower on high
contention.

Compile tested against some randconfig for different archs and tested against
android14-6.1 GKI kernel.

My testing is limited to resume path only; and general phone usage to make sure
nothing falls apart. Would be good to have some deadline specific testing done
too.

Based on v6.1.46

Original series:

	https://lore.kernel.org/lkml/20230508075854.17215-1-juri.lelli@redhat.com/

Thanks!

--
Qais Yousef

Dietmar Eggemann (2):
  sched/deadline: Create DL BW alloc, free & check overflow interface
  cgroup/cpuset: Free DL BW in case can_attach() fails

Juri Lelli (4):
  cgroup/cpuset: Rename functions dealing with DEADLINE accounting
  sched/cpuset: Bring back cpuset_mutex
  sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets
  cgroup/cpuset: Iterate only if DEADLINE tasks are present

 include/linux/cpuset.h  |  12 +-
 include/linux/sched.h   |   4 +-
 kernel/cgroup/cgroup.c  |   4 +
 kernel/cgroup/cpuset.c  | 246 ++++++++++++++++++++++++++--------------
 kernel/sched/core.c     |  41 +++----
 kernel/sched/deadline.c |  67 ++++++++---
 kernel/sched/sched.h    |   2 +-
 7 files changed, 246 insertions(+), 130 deletions(-)

-- 
2.34.1

On Sun, Aug 20, 2023 at 04:24:11PM +0100, Qais Yousef wrote:
> This is a backport of the series that fixes the way deadline bandwidth
> restoration is done which is causing noticeable delay on resume path. It also
> converts the cpuset lock back into a mutex which some users on Android too.
> I lack the details but AFAIU the read/write semaphore was slower on high
> contention.
> 
> Compile tested against some randconfig for different archs and tested against
> android14-6.1 GKI kernel.
> 
> My testing is limited to resume path only; and general phone usage to make sure
> nothing falls apart. Would be good to have some deadline specific testing done
> too.
> 
> Based on v6.1.46

I can't take these for only some branches, as you know.  Any reason why
you didn't also do 6.4.y?

thanks,

greg k-h

On 08/21/23 15:26, Greg KH wrote:
> On Sun, Aug 20, 2023 at 04:24:11PM +0100, Qais Yousef wrote:
> > This is a backport of the series that fixes the way deadline bandwidth
> > restoration is done which is causing noticeable delay on resume path. It also
> > converts the cpuset lock back into a mutex which some users on Android too.
> > I lack the details but AFAIU the read/write semaphore was slower on high
> > contention.
> > 
> > Compile tested against some randconfig for different archs and tested against
> > android14-6.1 GKI kernel.
> > 
> > My testing is limited to resume path only; and general phone usage to make sure
> > nothing falls apart. Would be good to have some deadline specific testing done
> > too.
> > 
> > Based on v6.1.46
> 
> I can't take these for only some branches, as you know.  Any reason why
> you didn't also do 6.4.y?

Beside being tunneled visioned towards LTS only, nope.

They apply cleanly on 6.4.y and preparing the patches now. I'm not sure I can
run any tests on 6.4.y though except maybe boot test on qemu.

Waiting for compile tests to finish and will post shortly.


Thanks!

--
Qais Yousef