Re: [PATCH v26 00/10] Simple Donor Migration for Proxy Execution

From: John Stultz

Date: Sat Apr 04 2026 - 02:07:41 EST


On Fri, Apr 3, 2026 at 10:49 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
>
> Hello John,
>
> On 4/4/2026 5:56 AM, John Stultz wrote:
> > I'm currently testing with my best guess of the combined suggestions
> > you've both tossed into this thread. Unfortunately I still trip over
> > state == TASK_RUNNING in proxy_deactivate(), so I'm trying to debug
> > that now.
> > (I think the issue is we hit the ttwu_queue_wakelist() case without
> > clearing PROXY_WAKING, so we need to clear_task_blocked_on() earlier
> > in ttwu, likely right after setting TASK_WAKING - that's looking ok so
> > far).
>
> That makes sense! I forgot we had that path for "p->on_cpu". Thank you
> for chasing that.
>
> Also looking at proxy-exec-v27-WIP, I think that:
>
> set_task_blocked_on_waking(p, NULL)
>
> in try_to_wake_up() can be moved after ttwu_state_match() since
> otherwise, we skip waking the task but ttwu() will end up marking
> it PROXY_WAKING for a spurious wakeup.
>
> I don't think there is any harm in keeping it that way but during the
> next pick, __schedule() will end up seeing PROXY_WAKING and will block
> the task.
>
> Until it receives a genuine wakeup, it cannot participate in proxy which
> is a missed opportunity.

So, actually, that caught my eye as well, and I think it can be
dropped completely. I just didn't have the time to experiment and
respin the series when I noticed it.

My thinking:
1) Since including your recent suggestions, proxy_needs_return()
handles both cases where its blocked_on a mutex or PROXY_WAKING.
2) If its not on the runqueue, we'll clear blocked_on anyway after
setting TASK_WAKING

So it seems like its harmless, but also unnecessary. I'll make sure
next week and will drop it in the next revision.


> > After I get this into a stable state, I'll try to polish it up a bit
> > and then re-layer the rest of the proxy-exec series on top (I do fret
> > the sleeping owner enqueueing will be more complicated).
>
> Ack! Let me go stare at it for a while but since you say it hasn't
> outright crashed your system, you may have taken care of everything
> already ;-)

I'll leave some testing running over the weekend to see if I catch anything.

Next week I'll do some trace analysis to make sure blocked owner
enqueuing is really behaving properly, which is my main concern right
now. Also need to get a sense of the performance situation to make
sure we're not regressing any further.

thanks
-john