linux-kernel - Re: [PATCH 0/6 v3] sched/mm: LRU drain flush on nohz

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] [day] [month] [year] [list]

Message-ID: <20250702115454.2183-1-hdanton@sina.com>
Date: Wed,  2 Jul 2025 19:54:52 +0800
From: Hillf Danton <hdanton@...a.com>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Michal Hocko <mhocko@...nel.org>,
	linux-mm@...ck.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/6 v3] sched/mm: LRU drain flush on nohz_full

On Tue, 1 Jul 2025 14:36:49 +0200 Frederic Weisbecker wrote
>Le Sat, Apr 12, 2025 at 10:58:22AM +0800, Hillf Danton a écrit :
>> On Thu, 10 Apr 2025 17:23:21 +0200 Frederic Weisbecker wrote
>> > Hi,
>> > 
>> > When LRUs are pending, the drain can be triggered remotely, whether the
>> > remote CPU is running in userspace in nohz_full mode or not. This kind
>> > of noise is expected to be caused by preparatory work before a task
>> > runs isolated in userspace. This patchset is a proposal to flush that
>> > before the task starts its critical work in userspace.
>> > 
>> Alternatively add a syscall for workloads on isolated CPUs to flush
>> this xxx and prepare that yyy before entering the critical work, instead
>> of adding random (nice) patches today and next month. Even prctl can
>> do lru_add_and_bh_lrus_drain(), and prctl looks more preferable over
>> adding a syscall.
>
>In an ideal world, this is indeed what we should do now. And I still wish we
>can do this in the future.
>
>The problem is that this has been tried by the past and the work was never
>finished because that syscall eventually didn't meet the need for the people
>working on it.
>
>I would volunteer to start a simple prctl to do such a flush, something that
>can be extended in the future, should the need arise, but such a new ABI must
>be thought through along with the CPU isolation community.
>
>Unfortunately there is no such stable CPU isolation community. Many developers
>in this area contribute changes and then switch to other things. As for the CPU
>isolation users, they are usually very quiet.
>
Given your footprint in the MAINTAINERS file,

HIGH-RESOLUTION TIMERS, TIMER WHEEL, CLOCKEVENTS
M:	Anna-Maria Behnsen <anna-maria@...utronix.de>
M:	Frederic Weisbecker <frederic@...nel.org>
M:	Thomas Gleixner <tglx@...utronix.de>

NOHZ, DYNTICKS SUPPORT
M:	Anna-Maria Behnsen <anna-maria@...utronix.de>
M:	Frederic Weisbecker <frederic@...nel.org>
M:	Ingo Molnar <mingo@...nel.org>
M:	Thomas Gleixner <tglx@...utronix.de>

POSIX CLOCKS and TIMERS
M:	Anna-Maria Behnsen <anna-maria@...utronix.de>
M:	Frederic Weisbecker <frederic@...nel.org>
M:	Thomas Gleixner <tglx@...utronix.de>

READ-COPY UPDATE (RCU)
M:	"Paul E. McKenney" <paulmck@...nel.org>
M:	Frederic Weisbecker <frederic@...nel.org> (kernel/rcu/tree_nocb.h)
M:	Neeraj Upadhyay <neeraj.upadhyay@...nel.org> (kernel/rcu/tasks.h)
M:	Joel Fernandes <joel@...lfernandes.org>
M:	Josh Triplett <josh@...htriplett.org>
M:	Boqun Feng <boqun.feng@...il.com>
M:	Uladzislau Rezki <urezki@...il.com>

I am happy to close the chance for you to deliver patch like a starter.

>I can't assume all the possible usecases myself and therefore I would easily do
>it wrong.
>
>In the meantime, the patchset here is a proposal that hopefully should work for
>many usecases.
>
>Thanks.
>
>-- 
>Frederic Weisbecker
>SUSE Labs