On Tue, 11 Apr 2023 12:15:41 +0200 Mike Galbraith <efault@xxxxxx> > On Mon, 2023-04-10 at 16:23 +0800, Hillf Danton wrote: > > > > In order to only narrow down the poor performance reported, make a tradeoff > > between runtime and latency simply by restoring sysctl_sched_min_granularity > > at tick preempt, given the known order on the runqueue. > > Tick preemption isn't the primary contributor to the scheduling delta, > it's wakeup preemption. If you look at the perf summaries of 5 minute > recordings on my little 8 rq box below, you'll see that the delta is > more than twice what a 250Hz tick could inflict. You could also just > turn off WAKEUP_PREEMPTION and watch the delta instantly peg negative. > > Anyway... > > Given we know preemption is markedly up, and as always a source of pain > (as well as gain), perhaps we can try to tamp it down a little without > inserting old constraints into the shiny new scheduler. > > The dirt simple tweak below puts a dent in the sting by merely sticking > with whatever decision EEVDF last made until it itself invalidates that > decision. It still selects via the same math, just does so the tiniest > bit less frenetically. > > --- > kernel/sched/fair.c | 3 +++ > kernel/sched/features.h | 6 ++++++ > 2 files changed, 9 insertions(+) > > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -950,6 +950,9 @@ static struct sched_entity *pick_eevdf(s > if (curr && (!curr->on_rq || !entity_eligible(cfs_rq, curr))) > curr =3D NULL; > > + if (sched_feat(GENTLE_EEVDF) && curr) > + return curr; > + This is rather aggressive, given latency-10 curr and latency-0 candidate at tick hit for instance. And along your direction a mild change is postpone the preempt wakeup to the next tick. +++ b/kernel/sched/fair.c @@ -7932,8 +7932,6 @@ static void check_preempt_wakeup(struct return; cfs_rq = cfs_rq_of(se); - update_curr(cfs_rq); - /* * XXX pick_eevdf(cfs_rq) != se ? */
