Re: [PATCH 4/6] sched/proxy: Switch proxy to use p->is_blocked

[John Stultz]

On Tue, May 26, 2026 at 4:16 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> Rather than gate the proxy paths with p->blocked_on, use p->is_blocked.
>
> This opens up the state: '->is_blocked && !->blocked_on' for future use.
>
> Notably, only proxy and delayed tasks can be ->on_rq && ->is_blocked, and it is
> guaranteed that sched_class::pick_task() will never return a delayed task.
> Therefore any task returned from pick_next_task() that has ->is_blocked set,
> must be a proxy task.

While this seems true, it also feels very subtle.

Just taking a step back, while it might be possible, I'm not sure I'm
totally seeing the benefit of doing this.

When we were playing around with the idea of keeping ptr+latch-bit in
the blocked_on field, using NULL+latch to replace PROXY_WAKING made
sense, but with is_blocked being used for more than just proxy logic,
I'm not sure encoding meaning across the two fields is particularly
intuitive (and def seems more error prone).  Is the special
PROXY_WAKING value really so awful?   Or maybe does it make sense to
have different values for is_blocked (DELAYED, PROXY) so we can better
separate the variants when combining with blocked_on?

It is a little funny to see how close this is getting to the separate
blocked_on_state + blocked_on management I had way back when before we
compressed that down with PROXY_WAKING. :)

thanks
-john