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