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]

Date: Sun, 7 Apr 2024 13:27:00 +0100
From: Qais Yousef <qyousef@...alina.io>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: 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>,
	John Stultz <jstultz@...gle.com>,
	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/05/24 18:16, Qais Yousef wrote:

> > 
> > All that to say that I think the weight is not applied on purpose.
> > This might work for your particular case but there are more changes to
> > be done if you want to apply prio inheritance between cfs tasks.
> > 
> > As an example, what about the impact of cgroup on the actual weight
> > and the inherited priority of a task ? If the owner and the waiter
> > don't belong to the same cgroup their own prio is meaningless... task
> > nice -20 in a group with a weight equal to nice 19 vs a task nice 19
> > in a group with a weight equals to nice -20
> 
> That is on my mind actually. But I thought it's a separate problem. That has to
> do with how we calculate the effective priority of the pi_task. And probably
> the sorting order to if we agree we need to revert the above. If that is done

Thinking more about it the revert is not the right thing to do. We want fair
tasks to stay ordered in FIFO for better fairness and avoid potential
starvation issues. It's just the logic for searching the top_waiter need to be
different. If the top_waiter is fair, then we need to traverse the tree to find
the highest nice value. We probably can keep track of this while adding items
to the tree to avoid the search.

For cgroup; is it reasonable (loosely speaking) to keep track of pi_cfs_rq and
detach_attach_task_cfs_rq() before the reweight? This seems the most
straightforward solution and will contain the complexity to keeping track of
cfs_rq. But it'll have similar issue to proxy execution where a task that
doesn't belong to the cgroup will consume its share..

Can we treat the two as separate problems? Or you think any solution must
address the two? Both must be fixed of course.

Thanks!

--
Qais Yousef