[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230816123716.GI980931@hirez.programming.kicks-ass.net>
Date: Wed, 16 Aug 2023 14:37:16 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Mike Galbraith <umgwanakikbuti@...il.com>
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 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
Powered by blists - more mailing lists