[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c20d4639-12d5-4794-a432-9fffcc1d9650@efficios.com>
Date: Thu, 30 Oct 2025 11:56:53 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
 Gabriele Monaco <gmonaco@...hat.com>, Michael Jeanson
 <mjeanson@...icios.com>, Jens Axboe <axboe@...nel.dk>,
 "Paul E. McKenney" <paulmck@...nel.org>,
 "Gautham R. Shenoy" <gautham.shenoy@....com>,
 Florian Weimer <fweimer@...hat.com>, Tim Chen <tim.c.chen@...el.com>,
 Yury Norov <yury.norov@...il.com>, Shrikanth Hegde <sshegde@...ux.ibm.com>
Subject: Re: [patch V3 19/20] sched/mmcid: Implement deferred mode change
On 2025-10-29 09:09, Thomas Gleixner wrote:
> When affinity changes cause an increase of the number of CPUs allowed for
> tasks which are related to a MM, that might results in a situation where
> the ownership mode can go back from per CPU mode to per task mode.
> 
> As affinity changes happen with runqueue lock held there is no way to do
> the actual mode change and required fixup right there.
> 
> Add the infrastructure to defer it to a workqueue. The scheduled work can
> race with a fork() or exit(). Whatever happens first takes care of it.
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
Powered by blists - more mailing lists
 
