Re: [PATCH 17/24] sched/fair: Implement delayed dequeue

Phil Auld
2024-11-01T14:42:39Z

On Fri, Nov 01, 2024 at 03:26:49PM +0100 Peter Zijlstra wrote:
> On Fri, Nov 01, 2024 at 09:38:22AM -0400, Phil Auld wrote:
>
> > How is delay dequeue causing more preemption?
>
> The thing delay dequeue does is it keeps !eligible tasks on the runqueue
> until they're picked again. Them getting picked means they're eligible.
> If at that point they're still not runnable, they're dequeued.
>
> By keeping them around like this, they can earn back their lag.
>
> The result is that the moment they get woken up again, they're going to
> be eligible and are considered for preemption.
>
>
> The whole thinking behind this is that while 'lag' measures the
> mount of service difference from the ideal (positive lag will have less
> service, while negative lag will have had too much service), this is
> only true for the (constantly) competing task.
>
> The moment a task leaves, will it still have had too much service? And
> after a few seconds of inactivity?
>
> So by keeping the deactivated tasks (artificially) in the competition
> until they're at least at the equal service point, lets them burn off
> some of that debt.
>
> It is not dissimilar to how CFS had sleeper bonus, except that was
> walltime based, while this is competition based.
>
>
> Notably, this makes a significant difference for interactive tasks that
> only run periodically. If they're not eligible at the point of wakeup,
> they'll incur undue latency.
>
>
> Now, I imagine FIO to have tasks blocking on IO, and while they're
> blocked, they'll be earning their eligibility, such that when they're
> woken they're good to go, preempting whatever.
>
> Whatever doesn't seem to enjoy this.
>
>
> Given BATCH makes such a terrible mess of things, I'm thinking FIO as a
> whole does like preemption -- so now it's a question of figuring out
> what exactly it does and doesn't like. Which is never trivial :/
>

Thanks for that detailed explanation.

I can confirm that FIO does like the preemption

NO_WAKEUP_P and DELAY - 427 MB/s
NO_WAKEUP_P and NO_DELAY - 498 MB/s
WAKEUP_P and DELAY - 519 MB/s
WAKEUP_P and NO_DELAY - 590 MB/s

Something in the delay itself
(extra tasks in the queue? not migrating the delayed task? ...)

I'll start looking at tracing next week.

Thanks,
Phil

--