Re: [PATCH 00/15] sched: EEVDF and latency-nice and/or slice-attr

From: Peter Zijlstra
Date: Wed Sep 06 2023 - 09:14:44 EST


On Wed, Aug 23, 2023 at 08:52:26PM -0400, Daniel Jordan wrote:

> We're investigating the other benchmarks, but here's what I've found so far
> with SPEC CPU. Some schedstats showed that eevdf is tick-preemption happy
> (patches below). These stats were taken over 1 minute near the middle of a ~26
> minute benchmark (502.gcc_r).
>
> Base: v6.5-rc4-based kernel
> EEVDF: Base + the latest EEVDF patches from tip/sched/core
>
> schedstat Base EEVDF
>
> sched 1,243,911 3,947,251
>
> tick_check_preempts 12,899,049
> tick_preempts 1,022,998
>
> check_deadline 15,878,463
> update_deadline 3,895,530
> preempt_deadline 3,751,580
>
> In both kernels, tick preemption is primarily what drives schedule()s.
> Preemptions happen over three times more often for EEVDF because in the base,
> tick preemption happens after a task has run through its ideal timeslice as a
> fraction of sched_latency (so two tasks sharing a CPU each get 12ms on a server
> with enough CPUs, sched_latency being 24ms), whereas with eevdf, a task's base
> slice determines when it gets tick-preempted, and that's 3ms by default. It
> seems SPEC CPU isn't liking the increased scheduling of EEVDF in a cpu-bound
> load like this. When I set the base_slice_ns sysctl to 12000000, the
> regression disappears.
>
> I'm still thinking about how to fix it.

EEVDF fundamentally supports per task request/slice sizes, which is the
primary motivator for finally finishing these patches.

So the plan is to extend sched_setattr() to allow tasks setting their
own ideal slice length. But we're not quite there yet.

Having just returned from PTO the mailbox is an utter trainwreck, but
I'll try and refresh those few patches this week for consideration.

In the meantime I think you found the right knob to twiddle.