[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3d10fbfb0171cc017e19adf39fa97a3160a76206.camel@gmail.com>
Date: Wed, 16 Aug 2023 17:38:20 +0200
From: Mike Galbraith <umgwanakikbuti@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Chen Yu <yu.c.chen@...el.com>,
kernel test robot <oliver.sang@...el.com>,
oe-lkp@...ts.linux.dev, lkp@...el.com,
linux-kernel@...r.kernel.org, x86@...nel.org,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [tip:sched/eevdf] [sched/fair] e0c2ff903c:
phoronix-test-suite.blogbench.Write.final_score -34.8% regression
On Wed, 2023-08-16 at 15:40 +0200, Peter Zijlstra wrote:
> On Wed, Aug 16, 2023 at 02:37:16PM +0200, Peter Zijlstra wrote:
> > On Mon, Aug 14, 2023 at 08:32:55PM +0200, Mike Galbraith wrote:
> >
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -875,6 +875,12 @@ static struct sched_entity *pick_eevdf(s
> > > if (curr && (!curr->on_rq || !entity_eligible(cfs_rq, curr)))
> > > curr = NULL;
> > >
> > > + /*
> > > + * Once selected, run the task to parity to avoid overscheduling.
> > > + */
> > > + if (sched_feat(RUN_TO_PARITY) && curr)
> > > + return curr;
> > > +
> > > while (node) {
> > > struct sched_entity *se = __node_2_se(node);
> > >
> >
> > So I read it wrong last night... but I rather like this idea. But
> > there's something missing. When curr starts a new slice it should
> > probably do a full repick and not stick with it.
> >
> > Let me poke at this a bit.. nice
>
> Something like so.. it shouldn't matter much now, but might make a
> difference once we start mixing different slice lengths.
Hm, that stash the deadline trick _seems_ to have cured the reason I
was inspired to added that XXX hunk.. no 'ew, that's a tad harsh'
latency penalty in sight <knocks wood>.
Here's hoping test bots don't have a cow.
>
> ---
> kernel/sched/fair.c | 12 ++++++++++++
> kernel/sched/features.h | 1 +
> 2 files changed, 13 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index fe5be91c71c7..128a78f3f264 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -873,6 +873,13 @@ static struct sched_entity *pick_eevdf(struct cfs_rq *cfs_rq)
> if (curr && (!curr->on_rq || !entity_eligible(cfs_rq, curr)))
> curr = NULL;
>
> + /*
> + * Once selected, run a task until it either becomes non-eligible or
> + * until it gets a new slice. See the HACK in set_next_entity().
> + */
> + if (sched_feat(RUN_TO_PARITY) && curr && curr->vlag == curr->deadline)
> + return curr;
> +
> while (node) {
> struct sched_entity *se = __node_2_se(node);
>
> @@ -5168,6 +5175,11 @@ set_next_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
> update_stats_wait_end_fair(cfs_rq, se);
> __dequeue_entity(cfs_rq, se);
> update_load_avg(cfs_rq, se, UPDATE_TG);
> + /*
> + * HACK, stash a copy of deadline at the point of pick in vlag,
> + * which isn't used until dequeue.
> + */
> + se->vlag = se->deadline;
> }
>
> update_stats_curr_start(cfs_rq, se);
> diff --git a/kernel/sched/features.h b/kernel/sched/features.h
> index 61bcbf5e46a4..f770168230ae 100644
> --- a/kernel/sched/features.h
> +++ b/kernel/sched/features.h
> @@ -6,6 +6,7 @@
> */
> SCHED_FEAT(PLACE_LAG, true)
> SCHED_FEAT(PLACE_DEADLINE_INITIAL, true)
> +SCHED_FEAT(RUN_TO_PARITY, true)
>
> /*
> * Prefer to schedule the task we woke last (assuming it failed
Powered by blists - more mailing lists