[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OS0PR01MB59222333D50ADBAD1786DA9A86C8A@OS0PR01MB5922.jpnprd01.prod.outlook.com>
Date: Sat, 7 Oct 2023 06:26:05 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Chen Yu <yu.c.chen@...el.com>,
Peter Zijlstra <peterz@...radead.org>
CC: Mike Galbraith <efault@....de>,
Marek Szyprowski <m.szyprowski@...sung.com>,
"bsegall@...gle.com" <bsegall@...gle.com>,
"bristot@...hat.com" <bristot@...hat.com>,
"chris.hyser@...cle.com" <chris.hyser@...cle.com>,
"corbet@....net" <corbet@....net>,
"dietmar.eggemann@....com" <dietmar.eggemann@....com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"joel@...lfernandes.org" <joel@...lfernandes.org>,
"joshdon@...gle.com" <joshdon@...gle.com>,
"juri.lelli@...hat.com" <juri.lelli@...hat.com>,
"kprateek.nayak@....com" <kprateek.nayak@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mingo@...nel.org" <mingo@...nel.org>,
"patrick.bellasi@...bug.net" <patrick.bellasi@...bug.net>,
Pavel Machek <pavel@....cz>, "pjt@...gle.com" <pjt@...gle.com>,
"qperret@...gle.com" <qperret@...gle.com>,
"qyousef@...alina.io" <qyousef@...alina.io>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
"timj@....org" <timj@....org>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"youssefesmat@...omium.org" <youssefesmat@...omium.org>,
"mgorman@...e.de" <mgorman@...e.de>,
"linux-renesas-soc@...r.kernel.org"
<linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH] sched/fair: fix pick_eevdf to always find the correct se
Hi Chen Yu,
> Subject: Re: [PATCH] sched/fair: fix pick_eevdf to always find the correct
> se
>
> On 2023-10-06 at 21:24:45 +0200, Peter Zijlstra wrote:
> > On Fri, Oct 06, 2023 at 05:55:01PM +0200, Peter Zijlstra wrote:
> >
> > > And yeah, min_deadline is hosed somehow.
> > >
> > > migration/28-185 [028] d..2. 70.264274: validate_cfs_rq: --- /
> > > migration/28-185 [028] d..2. 70.264277: __print_se:
> ffff88845cf48080 w: 1024 ve: -58857638 lag: 870381 vd: -55861854 vmd: -
> 66302085 E (11372/tr)
> > > migration/28-185 [028] d..2. 70.264280: __print_se:
> ffff88810d165800 w: 25 ve: -80323686 lag: 22336429 vd: -41496434 vmd: -
> 66302085 E (-1//autogroup-31)
> > > migration/28-185 [028] d..2. 70.264282: __print_se:
> ffff888108379000 w: 25 ve: 0 lag: -57987257 vd: 114632828 vmd: 114632828 N
> (-1//autogroup-33)
> > > migration/28-185 [028] d..2. 70.264283: validate_cfs_rq:
> min_deadline: -55861854 avg_vruntime: -62278313462 / 1074 = -57987256
> > >
> > > I need to go make dinner (kids hungry), but I'll see if I can figure
> > > out how this happens...
> >
> > *sigh*, does the below help?
> >
> > ---
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index
> > 04fbcbda97d5..6a670f119efa 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -3632,6 +3747,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq,
> struct sched_entity *se,
> > */
> > deadline = div_s64(deadline * old_weight, weight);
> > se->deadline = se->vruntime + deadline;
> > + min_deadline_cb_propagate(&se->run_node, NULL);
> > }
> >
> > #ifdef CONFIG_SMP
>
> Is it because without this patch, the se->deadline is not always synced
> with se->min_deadline, then in pick_eevdf() the following condition could
> not be met, thus we get a NULL candidate and has to pick the leftmost one?
> if (se->deadline == se->min_deadline)
>
> Regarding the circular locking warning triggered by printk, does it mean we
> should not get a NULL candidate from __pick_eevdf() in theory? And besides,
> we should not use printk with rq lock hold?
Is it not a useful error log? At least from the initial report Marek Szyprowski doesn't see "EEVDF scheduling fail, picking leftmost" but seen only warning triggered by this in the logs.
Cheers,
Biju
Powered by blists - more mailing lists