Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

[Michal Koutný]

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@xxxxxxxxxx> 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

Attachment: signature.asc
Description: PGP signature