Hello Waiman. (I have no opinion on the overall locking reworks, only the bits about v1 migrations caught my attention.)
On Mon, Apr 01, 2024 at 10:58:57AM -0400, Waiman Long <[email protected]> wrote: ... > @@ -4383,12 +4377,20 @@ hotplug_update_tasks_legacy(struct cpuset *cs, > /* > * Move tasks to the nearest ancestor with execution resources, > * This is full cgroup operation which will also call back into > - * cpuset. Should be done outside any lock. > + * cpuset. Execute it asynchronously using workqueue. ...to avoid deadlock on cpus_read_lock Is this the reason? Also, what happens with the tasks in the window till the migration happens? Is it handled gracefully that their cpu is gone? > - if (is_empty) { > - mutex_unlock(&cpuset_mutex); > - remove_tasks_in_empty_cpuset(cs); > - mutex_lock(&cpuset_mutex); > + if (is_empty && css_tryget_online(&cs->css)) { > + struct cpuset_remove_tasks_struct *s; > + > + s = kzalloc(sizeof(*s), GFP_KERNEL); Is there a benefit of having a work for each cpuset? Instead of traversing whole top_cpuset once in the async work. Thanks, Michal
signature.asc
Description: PGP signature
