Re: [RESEND PATCH v13 0/9] timers: Exclude isolated cpus from timer migration

Gabriele Monaco
2025-10-31T14:04:02Z

On Fri, 2025-10-31 at 14:48 +0100, Frederic Weisbecker wrote:
> Le Thu, Oct 30, 2025 at 01:57:50PM -0400, Waiman Long a écrit :
> > These 2 cpuset patches are actually independent of the timer related
> > changes. The purpose of these two patches are to prevent the cpuset code
> > from adding isolated CPUs in such a way that all the nohz_full HK CPUs
> > become domain-isolated. This is a corner case that normal users won't try to
> > do. The patches are just an insurance policy to ensure that users can't do
> > that. This is complementary to the sched/isolation patch that limits what
> > CPUs can be put to the isolcpus and nohz_full boot parameters. All these
> > patches are independent of the timer related changes, though you can say
> > that the solution will only be complete if all the pieces are in place.
>
> Right but there will be a conflict if the timer patches don't have
> the rename of update_unbound_workqueue_cpumask().
>

Waiman, are you referring to [1]?

Since that is an RFC, couldn't you just take in those patches before merging [1]
and adapt just that one directly in the cpuset tree? I guess git should figure
it out if we keep my cpuset patches in both trees (or at least 5/9), as long as
the conflicts come in later commits.
Different story is if you already took some conflicting patches in, then I can
look into rebasing as Frederic suggests.

Thanks,
Gabriele

[1] -
https://lore.kernel.org/lkml/20251025064844.495525-8-chenridong@huaweicloud.com

> > There are another set of pending cpuset patches from Chen Ridong that does
> > some restructuring of the cpuset code that will likely have some conflicts
> > with these 2 patches. So I would like to settle the cpuset changes to avoid
> > future conflicts.
>
> Ok so it looks like there will be conflicts eventually during the merge
> window. In that case it makes sense to take Gabriel cpuset patches but
> he'll need to rebase the rest on top of the timer tree.
>
> Thanks.
>
> >
> > Cheers,
> > Longman
> >