linux-kernel - Re: [PATCH] sched/pi: Reweight fair_policy() tasks when inheriting prio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240410154727.4yh5tcnpb6zwxuub@airbuntu>
Date: Wed, 10 Apr 2024 16:47:27 +0100
From: Qais Yousef <qyousef@...alina.io>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: John Stultz <jstultz@...gle.com>, Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Daniel Bristot de Oliveira <bristot@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Joel Fernandes <joel@...lfernandes.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	linux-kernel@...r.kernel.org, Yabin Cui <yabinc@...gle.com>
Subject: Re: [PATCH] sched/pi: Reweight fair_policy() tasks when inheriting
 prio

On 04/10/24 11:13, Vincent Guittot wrote:

> > > Without cgroup, the solution could be straightforward but android uses
> > > extensively cgroup AFAICT and update_cfs_group() makes impossible to
> > > track the top cfs waiter and its "prio"
> >
> > :(
> >
> > IIUC the issue is that we can't easily come up with a single number of
> > 'effective prio' for N level hierarchy and compare it with another M level
> > hierarchy..
> 
> And then how do you apply it on the hierarchy ?

(I am not disagreeing with you, just trying to state the reasons more
explicitly)

I think the application is easy, attach to the leaf cfs_rq? Which IIUC
correctly what should happen with proxy execution, but by consuming the context
of the donor directly without having explicitly to move the lock owner.

Finding out which hierarchy actually has the highest effective share is not
straightforward I agree. And if we combine a potential operation of something
that could move any waiting task to a different hierarchy at anytime, this gets
even more complex.

I need to go and find more info, but seems Windows has some kind of boost
mechanism to help the lock owner to release the lock faster. I wonder if
something like that could help as interim solution. What we could do is move
the task to root group as a boost with the simple reweight operation proposed
here applied. As soon as it releases the lock we should restore it.

>From what I heard in Windows this boost happens randomly (don't quote me on
this). I am not sure could be our trigger mechanism. We sure don't want to do
this unconditionally otherwise we break fairness.

Maybe there are easier ways to introduce a simple such boost mechanism..