Re: [PATCH] sched/deadline: Ignore proxy-exec sched_yield()

[Juri Lelli]

Hi Christian,

On 07/07/26 18:45, Christian Loehle wrote:
> With proxy execution, rq->curr is the execution context while rq->donor is
> the donating context. rq->curr's sched_yield() is dispatched through
> the donor class so that proxy execution follows the effective scheduling
> context.
> 
> For SCHED_DEADLINE, this is too strong. yield_task_dl() does not just ask
> for another task of equal priority to get to run, it marks the current DL
> entity as yielded and forces it to sleep until replenishment. These
> yield semantics are fundamentally different from FIFO/RR (where if no
> equal-priority tasks are runnable, no harm done, they get picked again
> immediately) or OTHER (also doesn't cause priority inversion), so do not
> mix these semantics by ignoring a sched_yield() on DL donors.
> 
> Fixes: 127b90315ca0 ("sched/proxy: Yield the donor task")
> Signed-off-by: Christian Loehle <christian.loehle@xxxxxxx>
> ---
> I have just looked through the old discussion and noticed that the
> argument for always doing donor yielding doesn't hold for DL and ignoring
> it should be the safer and saner handling. Haven't actually encountered
> the issue.
> old discussion:
> https://lore.kernel.org/oe-lkp/202510211205.1e0f5223-lkp@xxxxxxxxx/T/#m0ea38261f80fc06018ca140eb0d115b11299cfc1
> https://lore.kernel.org/lkml/20251106104022.195157-1-sieberf@xxxxxxxxxx/

It seems to make sense to me. Thinking more about it, at least and
especially for DEADLINE, calling sched_yield while holding a mutex
doesn't seem the right thing to do. Ideally one calls yield when current
activation is done with its work. So, we could flag such calls with some
kind of warning, but it might be too invasive.

Anyway, we certainly don't want to apply the DEADLINE yield semantic to
the donor, so, unless we want to be more strict about it

Acked-by: Juri Lelli <juri.lelli@xxxxxxxxxx>

Thanks!
Juri