Re: [PATCH] sched/proxy_exec: Optimize proxy_tag_curr() pushable removal

[John Stultz]

On Tue, Mar 3, 2026 at 7:40 AM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> On 3/3/2026 5:27 PM, soolaugust@xxxxxxxxx wrote:
> > The SAVE/RESTORE cycle achieves pushable removal only indirectly:
> > enqueue_task_rt/dl() suppresses re-enqueue into the pushable
> > list when task_is_blocked(owner) is true.  The same result is
> > obtained more directly by calling dequeue_pushable_task() or
> > dequeue_pushable_dl_task() once, without any of the side effects.
> >
> > Replace the workaround with per-class direct calls:
>
> I had this question in the past and from my reading, I think we
> can safely call the dequeue_pushable*() helper (John might have some
> notes on these bits) but that direct call is just horrible!
>
> Why can't we just have a sched_class->proxy_tag_curr(rq, p) or such
> and just call it if a "sched_class" populates it?

Yeah, I agree we should use a sched_class-> method rather then doing a
big conditional tree.

> Also I forgot how the current context gets put back on the pushable list
> once the proxy is done since at that point it is just a preempted task
> on the CPU.
>
> John, do you remember how this happens?
>
> I think we might also need a proxy_untag_current() which calls into
> enqueue_pushable.*_task() which does the minimal bits of put_prev_task()
> undoing the tag and possibly queuing some balance callbacks which would
> have been skipped by set_next_task() on not seeing any pushable tasks
> at the time of donor pick?

Oh hmm, good catch! So I think you're right that right now we're
leaning on the owner to be run without a donor before we return it to
the pushable list, which isn't great.

I'll take a swing at addressing this (along with your other feedback -
this year has been hectic and I've only just now finally managed to
get back to proxy-exec upstreaming efforts!) for v25.

Thanks again for the careful review and feedback!
-john