linux-kernel - Re: [PATCH v3 0/5] Defer throttle when task exits to user

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: <xhsmhms7klsl7.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
Date: Wed, 27 Aug 2025 16:58:12 +0200
From: Valentin Schneider <vschneid@...hat.com>
To: Aaron Lu <ziqianlu@...edance.com>, Ben Segall <bsegall@...gle.com>, K
 Prateek Nayak <kprateek.nayak@....com>, Peter Zijlstra
 <peterz@...radead.org>, Chengming Zhou <chengming.zhou@...ux.dev>, Josh
 Don <joshdon@...gle.com>, Ingo Molnar <mingo@...hat.com>, Vincent Guittot
 <vincent.guittot@...aro.org>, Xi Wang <xii@...gle.com>
Cc: linux-kernel@...r.kernel.org, Juri Lelli <juri.lelli@...hat.com>,
 Dietmar Eggemann <dietmar.eggemann@....com>, Steven Rostedt
 <rostedt@...dmis.org>, Mel Gorman <mgorman@...e.de>, Chuyi Zhou
 <zhouchuyi@...edance.com>, Jan Kiszka <jan.kiszka@...mens.com>, Florian
 Bezdeka <florian.bezdeka@...mens.com>, Songtang Liu
 <liusongtang@...edance.com>
Subject: Re: [PATCH v3 0/5] Defer throttle when task exits to user

On 15/07/25 15:16, Aaron Lu wrote:
> There are consequences because of this new throttle model, e.g. for a
> cfs_rq that has 3 tasks attached, when 2 tasks are throttled on their
> return2user path, one task still running in kernel mode, this cfs_rq is
> in a partial throttled state:
> - Should its pelt clock be frozen?
> - Should this state be accounted into throttled_time?
>
> For pelt clock, I chose to keep the current behavior to freeze it on
> cfs_rq's throttle time. The assumption is that tasks running in kernel
> mode should not last too long, freezing the cfs_rq's pelt clock can keep
> its load and its corresponding sched_entity's weight. Hopefully, this can
> result in a stable situation for the remaining running tasks to quickly
> finish their jobs in kernel mode.

OK, I finally got to testing the PELT side of things :-)

I shoved a bunch of periodic tasks in a CPU cgroup with quite low limits
(1ms runtime, 10ms period); I looked at the _avg values using the
trace_pelt* tracepoints.

Overall there isn't much change to the averages themselves. There are more
updates since the tasks are genuinely dequeued/enqueued during a throttle
cycle, but that's expected.

I'll wait for your next version, but you can have:

Tested-by: Valentin Schneider <vschneid@...hat.com>