Yes, it protects against cpu hot-plug or hot-unplug; cpu_online_map is
guaranteed to be unchanged while the mutex is being held.
It doesn't need to protect the per-task cpus_allowed per se, that's
already protected. If a task's cpu affinity changes during a call to
set_cpus_allowed(), the migration thread will notice the change when it
tries to deactive the task and activate it on the destination cpu. It
then becomes a no-op.
That's a consequence of the fact that we can't migrate current and need a
kthread, particularly the source cpu's runqueue migration thread, to do it
when it's scheduled. A migration request such as that includes a
completion variable so that the set_cpus_allowed() waits until it has
either been migrated or changed cpu affinity again.
Right, the destination cpu will not be hot-unplugged out from underneath
the task during migration.
Not necessarily, you can iterate through a list of tasks and change their
cpu affinity (represented by task->cpus_allowed) by migrating them away
while task->cpuset->cpus_allowed remains unchanged. The hotcpu notifier
cpuset_handle_cpuhp() will update that when necessary for cpu hot-plug or
hot-unplug events.
So it's entirely possible that a cpu will be downed during your iteration
of tasks, but that's fine. Just as long as it isn't downed during the
migration. The cpuset's cpus_allowed will be updated by the hotcpu
notifier and sched_hotcpu_mutex will protect from unplugged cpus around
the set_cpus_allowed() call, which checks for intersection between your
new cpumask and cpu_online_map.
The hotcpu notifier protects you there as well.
common_cpu_mem_hotplug_unplug() explicitly sets them.
Same as above, except now you're using
guarantee_online_cpus_mems_in_subtree().
It guards cpu_online_map from being changed while it's held.
It's needed to serialize with other migrations such as sched_setaffinity()
and you can use it since all migrations will inherently need this type of
protection. It makes the new cpumask consistent with cpu_online_map only
so far as that it's a subset; otherwise, set_cpus_allowed() will fail.
The particular destination cpu is chosen as any online cpu, which we know
won't be downed because we're holding sched_hotcpu_mutex.
David
-
