linux-kernel - Re: [PATCH v2 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <xm26qzyyb6cn.fsf@google.com>
Date: Wed, 02 Jul 2025 15:00:56 -0700
From: Benjamin Segall <bsegall@...gle.com>
To: Aaron Lu <ziqianlu@...edance.com>
Cc: Valentin Schneider <vschneid@...hat.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>,
  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>
Subject: Re: [PATCH v2 0/5] Defer throttle when task exits to user

Aaron Lu <ziqianlu@...edance.com> writes:

> 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.

I suppose the way that this would go wrong would be CPU 1 using up all
of the quota, and then a task waking up on CPU 2 and trying to run in
the kernel for a while. I suspect pelt time needs to also keep running
until all the tasks are asleep (and that's what we have been running at
google with the version based on separate accounting, so we haven't
accidentally done a large scale test of letting it pause).

Otherwise it does look ok, so long as we're ok with increasing distribute
time again.