Re: [PATCH 23/30] sched/fair: handle tick expiry under lazy preemption

[Juri Lelli]

Hi Ankur,

On 12/02/24 21:55, Ankur Arora wrote:
> The default policy for lazy scheduling is to schedule in exit-to-user,
> assuming that would happen within the remaining time quanta of the
> task.
> 
> However, that runs into the 'hog' problem -- the target task might
> be running in the kernel and might not relinquish CPU on its own.
> 
> Handle that by upgrading the ignored tif_resched(NR_lazy) bit to
> tif_resched(NR_now) at the next tick.
> 
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Juri Lelli <juri.lelli@xxxxxxxxxx>
> Cc: Vincent Guittot <vincent.guittot@xxxxxxxxxx>
> Originally-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Link: https://lore.kernel.org/lkml/87jzshhexi.ffs@tglx/
> Signed-off-by: Ankur Arora <ankur.a.arora@xxxxxxxxxx>
> 
> ---
> Note:
>   Instead of special casing the tick, it might be simpler to always
>   do the upgrade on the second resched_curr().
> 
>   The theoretical problem with doing that is that the current
>   approach deterministically provides a well-defined extra unit of
>   time. Going with a second resched_curr() might mean that the
>   amount of extra time the task gets depends on the vagaries of
>   the incoming resched_curr() (which is fine if it's mostly from
>   the tick; not fine if we could get it due to other reasons.)
> 
>   Practically, both performed equally well in my tests.
> 
>   Thoughts?

I'm still digesting the series, so I could simply be confused, but I
have the impression that the extra unit of time might be a problem for
deadline (and maybe rt as well?).

For deadline we call resched_curr_tick() from the throttle part of
update_curr_dl_se() if the dl_se happens to not be the leftmost anymore,
so in this case I believe we really want to reschedule straight away and
not wait for the second time around (otherwise we might be breaking the
new leftmost tasks guarantees)?

Thanks,
Juri