From: Jan Beulich <email@example.com> To: Dario Faggioli <firstname.lastname@example.org>, George Dunlap <email@example.com> Cc: Ian Jackson <firstname.lastname@example.org>, email@example.com Subject: Ping: [Bugfix PATCH for-4.15] xen: credit2: fix per-entity load tracking when continuing running Date: Tue, 27 Apr 2021 10:35:48 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <161615605709.5036.4052641880659992679.stgit@Wayrath> On 19.03.2021 13:14, Dario Faggioli wrote: > If we schedule, and the current vCPU continues to run, its statistical > load is not properly updated, resulting in something like this, even if > all the 8 vCPUs are 100% busy: > > (XEN) Runqueue 0: > (XEN) [...] > (XEN) aveload = 2097152 (~800%) > (XEN) [...] > (XEN) Domain: 0 w 256 c 0 v 8 > (XEN) 1: [0.0] flags=2 cpu=4 credit=9996885 [w=256] load=35 (~0%) > (XEN) 2: [0.1] flags=2 cpu=2 credit=9993725 [w=256] load=796 (~0%) > (XEN) 3: [0.2] flags=2 cpu=1 credit=9995885 [w=256] load=883 (~0%) > (XEN) 4: [0.3] flags=2 cpu=5 credit=9998833 [w=256] load=487 (~0%) > (XEN) 5: [0.4] flags=2 cpu=6 credit=9998942 [w=256] load=1595 (~0%) > (XEN) 6: [0.5] flags=2 cpu=0 credit=9994669 [w=256] load=22 (~0%) > (XEN) 7: [0.6] flags=2 cpu=7 credit=9997706 [w=256] load=0 (~0%) > (XEN) 8: [0.7] flags=2 cpu=3 credit=9992440 [w=256] load=0 (~0%) > > As we can see, the average load of the runqueue as a whole is, instead, > computed properly. > > This issue would, in theory, potentially affect Credit2 load balancing > logic. In practice, however, the problem only manifests (at least with > these characteristics) when there is only 1 runqueue active in the > cpupool, which also means there is no need to do any load-balancing. > > Hence its real impact is pretty much limited to wrong per-vCPU load > percentages, when looking at the output of the 'r' debug-key. > > With this patch, the load is updated and displayed correctly: > > (XEN) Runqueue 0: > (XEN) [...] > (XEN) aveload = 2097152 (~800%) > (XEN) [...] > (XEN) Domain info: > (XEN) Domain: 0 w 256 c 0 v 8 > (XEN) 1: [0.0] flags=2 cpu=4 credit=9995584 [w=256] load=262144 (~100%) > (XEN) 2: [0.1] flags=2 cpu=6 credit=9992992 [w=256] load=262144 (~100%) > (XEN) 3: [0.2] flags=2 cpu=3 credit=9998918 [w=256] load=262118 (~99%) > (XEN) 4: [0.3] flags=2 cpu=5 credit=9996867 [w=256] load=262144 (~100%) > (XEN) 5: [0.4] flags=2 cpu=1 credit=9998912 [w=256] load=262144 (~100%) > (XEN) 6: [0.5] flags=2 cpu=2 credit=9997842 [w=256] load=262144 (~100%) > (XEN) 7: [0.6] flags=2 cpu=7 credit=9994623 [w=256] load=262144 (~100%) > (XEN) 8: [0.7] flags=2 cpu=0 credit=9991815 [w=256] load=262144 (~100%) > > Signed-off-by: Dario Faggioli <email@example.com> > --- > Cc: George Dunlap <firstname.lastname@example.org> > Cc: Ian Jackson <email@example.com> > --- > Despite the limited effect, it's a bug. So: > - it should be backported; > - I think it should be included in 4.15. The risk is pretty low, for > the same reasons already explained when describing its limited impact. I'm a little puzzled to find this is still in my waiting-to-go-in folder, for not having had an ack (or otherwise). George? Jan > --- > xen/common/sched/credit2.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c > index eb5e5a78c5..b3b5de94cf 100644 > --- a/xen/common/sched/credit2.c > +++ b/xen/common/sched/credit2.c > @@ -3646,6 +3646,8 @@ static void csched2_schedule( > runq_remove(snext); > __set_bit(__CSFLAG_scheduled, &snext->flags); > } > + else > + update_load(ops, rqd, snext, 0, now); > > /* Clear the idle mask if necessary */ > if ( cpumask_test_cpu(sched_cpu, &rqd->idle) ) > > >
next prev parent reply other threads:[~2021-04-27 8:36 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-19 12:14 Dario Faggioli 2021-04-27 8:35 ` Jan Beulich [this message] 2021-05-28 15:18 ` Ping: " Dario Faggioli 2021-06-07 11:44 ` George Dunlap
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Ping: [Bugfix PATCH for-4.15] xen: credit2: fix per-entity load tracking when continuing running' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).