lkml.org 
[lkml]   [2024]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2024-05-27 16:19    [W:0.060 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site