Messages in this thread | | | Date | Tue, 2 Apr 2024 16:13:41 +0200 | From | Michal Koutný <> | Subject | Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous |
| |
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 <longman@redhat.com> 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
[unhandled content-type:application/pgp-signature] | |