Messages in this thread | | | Date | Wed, 16 Aug 2023 22:04:05 +0200 | From | Peter Zijlstra <> | Subject | Re: [tip:sched/eevdf] [sched/fair] e0c2ff903c: phoronix-test-suite.blogbench.Write.final_score -34.8% regression |
| |
On Wed, Aug 16, 2023 at 05:38:20PM +0200, Mike Galbraith wrote: > 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.
You want to write up a Changelog for this, or should I attempt to write one?
| |