linux-kernel - Re: [RFC PATCH 4/5] sched/fair: Use EAS also when overutilized

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Zv5pSdRsSsfRSNsJ@google.com>
Date: Thu, 3 Oct 2024 09:52:09 +0000
From: Quentin Perret <qperret@...gle.com>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
	mgorman@...e.de, vschneid@...hat.com, lukasz.luba@....com,
	rafael.j.wysocki@...el.com, linux-kernel@...r.kernel.org,
	qyousef@...alina.io, hongyan.xia2@....com
Subject: Re: [RFC PATCH 4/5] sched/fair: Use EAS also when overutilized

On Thursday 03 Oct 2024 at 10:57:55 (+0200), Vincent Guittot wrote:
> The current pelt algorithm track actual cpu utilization and can go
> above cpu capacity (but not above 1024) so a  task utilization can
> become bigger than a little cpu capacity

Right, the time invariance thing. So yes, I still think that a mix of
co-scheduling and task migrations (which is likely common in the
overcommitted state) will cause some CPUs to appear lightly utilized at
least transiently, hence tricking feec() into thinking it can help when
it really can't.

> As replied to Lukasz, if you want to discard utilization of a trask
> you need to check the previous cpu

Please help me out here because I'm still not quite sure what we're
talking about. Could you please expand a bit?

Thanks,
Quentin