Re: [RFC][PATCH 2/2] sched: proxy-exec: Add allow/prevent_migration hooks in the sched classes for proxy_tag_curr

[K Prateek Nayak]

Hello Peter,

On 3/4/2026 6:48 PM, Peter Zijlstra wrote:
> +static inline void set_proxy_task(struct task_struct *p)
>  {
> -	if (!sched_proxy_exec())
> -		return;
> -	/*
> -	 * pick_next_task() calls set_next_task() on the chosen task
> -	 * at some point, which ensures it is not push/pullable.
> -	 * However, the chosen/donor task *and* the mutex owner form an
> -	 * atomic pair wrt push/pull.
> -	 *
> -	 * Make sure owner we run is not pushable. Unfortunately we can
> -	 * only deal with that by means of a dequeue/enqueue cycle. :-/
> -	 */
> -	dequeue_task(rq, owner, DEQUEUE_NOCLOCK | DEQUEUE_SAVE);
> -	enqueue_task(rq, owner, ENQUEUE_NOCLOCK | ENQUEUE_RESTORE);
> +	WARN_ON_ONCE(p->migration_flags & MDF_PROXY);
> +	p->migration_flags |= MDF_PROXY;
> +	p->migration_disabled++;
> +}
> +
> +static inline void put_proxy_task(struct task_struct *p)
> +{
> +	WARN_ON_ONCE(!(p->migration_flags & MDF_PROXY));
> +	p->migration_flags &= ~MDF_PROXY;
> +	p->migration_disabled--;

Note: I'm not too familiar with the set_affinity bits so my
understanding might be all wrong but ...

Doesn't the set_affinity bits have a completion based wait for tasks
that are migration disabled? If we have a case like:

       P0                                             P1
       ==                                             ==

  migrate_disable()
    p->migration_disabled++; /* 1 */
  ...
  mutex_lock()
  ...

  /* preempted */
  /* proxied */
  set_proxy_task(P0)
    p->migration_disabled++; /* 2 */
  ...
  /* Continues running */
                                        set_cpus_allowed_ptr(P0)
                                          /* Task CPU not in the new mask. */
                                          affine_move_task()
                                            /*
                                             * blocks as per the comment
                                             * above affine_move_task().
                                             */
  migrate_enable()
   if (p->migration_disabled > 1)
     p->migration_disabled--; /* 1 */
     return;
  ...
  mutex_unlock();
  /* Goes into schedule. */
  put_proxy_task(P0)
    p->migration_disabled--; /* 0 */

  /* !!! Who does the migration + wakeup? !!! */


Isn't it up to the last migrate_enable() (or in this case,
put_proxy_task()) to schedule in the stopper and push the prev to
another CPU? Or is it handled in some other way?

>  }

-- 
Thanks and Regards,
Prateek