Re: [PATCH-next 00/23] cgroup/cpuset: Enable runtime update of nohz_full and managed_irq CPUs

Waiman Long <[email protected]>
Newsgroups org.kernel.vger.rcu,org.kernel.vger.cgroups,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 6/24/26 2:34 AM, Jing Wu wrote:
> Hi Waiman,
>
> Thomas Gleixner suggested we coordinate, so reaching out directly.
>
> We have been working on a similar feature called Dynamic Housekeeping
> Management (DHM) [1][2][3][4]. The RFC was posted on 2026-02-06, v1 on
> 2026-03-25, and v2 on 2026-04-13 — a week before your series appeared.
> It seems we developed these independently in parallel.
>
> After Thomas's review of DHM v3, we are rebuilding v4 around the
> CPU-by-CPU offline/online hotplug mechanism, which aligns with the
> direction of your series.
>
> There is one key difference in scope worth discussing:
>
>    Your series requires "nohz_full=" to be present at boot (even with
>    an empty CPU list) to opt into runtime updates. DHM targets systems
>    where nohz_full= was never configured at boot — enabling CPU noise
>    isolation purely at runtime without any boot-time setup.
>
>    This requires making the nohz_full infrastructure activatable at
>    runtime for the first time, rather than just extending an already-
>    initialized boot configuration.
>
> Before we start coding v4, a few questions:
>
>    1. Are you planning a v2 of your series? If so, what is your
>       timeline? We want to avoid duplicating effort on the subsystem
>       patches (tick, RCU, genirq).

Yes, I am planning to send out a v2 in a few weeks depending on whether 
I can finish the other works that I am doing right now.


>
>    2. Would you be open to extending your series to cover the
>       "no boot parameter" use case, or do you think it is better kept
>       as a separate series?
The reason to make the v1 series depending on the nohz_full parameter is 
basically a short cut as some code will change its behavior slightly 
depending on if the nohz_full parameter is set. By making it optional, 
we just have to add more code to enable them. It is more work, but 
doable. I will make that optional in the next version, but I probably 
won't have all the needed code other than the essential ones and the 
rests will be handled in a followup patch series.
>
>    3. Are there specific patches in your series where you would welcome
>       our contribution directly?

I have broken down the shutdown callback into separate portions as 
suggested by Thomas. The other major change that I am working on is to 
try to shutdown to only CPUHP_AP_OFFLINE state instead of all the way 
down to CPUHP_OFFLINE. That will require some adjustments to the 
nohz_full related hotplug functions. I have some ideas of what needs to 
be done. However, I haven't looked into RCU yet. I know RCU support 
changing the nocb mask for fully offline CPUs, I will need to find out 
if it possible to do that for partially offline CPUs.

The work has been suspended for a while as I have other works to do. 
Hopefully I can restart it soon to further refresh my memory and we can 
discuss collaboration at that point.

Cheers,
Longman


>
> Happy to collaborate on a unified approach.
>
> [1] DHM RFC (2026-02-06): https://lore.kernel.org/r/20260206-feature-dynamic_isolcpus_dhei-v1-0-00a711eb0c74@gmail.com
> [2] DHM v1  (2026-03-25): https://lore.kernel.org/r/[email protected]
> [3] DHM v2  (2026-04-13): https://lore.kernel.org/r/[email protected]
> [4] DHM v3  (2026-06-18): https://lore.kernel.org/r/[email protected]
> [5] Your series v1 (2026-04-20): https://lore.kernel.org/r/[email protected]
>
> Jing Wu <[email protected]>
> Qiliang Yuan <[email protected]>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.