On 1/8/25 2:35 PM, Tejun Heo wrote:
Hello,
On Wed, Jan 08, 2025 at 02:27:07PM -0500, Waiman Long wrote:
On 1/8/25 11:53 AM, Tejun Heo wrote:
This patch looks good me. However, this does raise a question that I
overlook when I made hotplug operation synchronous while task transfer, if
needed, remained asynchronous. There is a very slight chance where we keep
removing tasks added after execution capability is restored. As cgroup v1 is
in the process of being deprecated, do you think we still need to do
something to address this issue?
I *think* that should be fine. In cgroup1, the kernel is making irreversible
system config changes when a cgroup loses all its CPUs. I have a hard time
imagining use cases that would depend on the the exact ordering of
operations at that point. The auto transfer-out was always the last ditch
measure to not leave the system in a broken state after all. If someone's
depending on the transfer out being strictly ordered w.r.t. the cgroup
losing all CPUs and then gaining some, let's hear why the hell that ordering
matters first.
Thanks for the explanation.
It is not the strict ordering that I am worrying about. It is all about
the possibility of hitting some race conditions.
I am thinking of a scenario where a cpuset loses all its CPUs in
hotunplug and then restored by adding other CPUs. There is chance that
the css will be operated on concurrently by the auto-transfer task and
another task moving new task to the css. I am not sure if that will be a
problem or not. Anyway, it is very rare that we will be in such a situation.
Thanks,
Longman
