[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen: sched: improve debug dump output.
Hi Dario, I'm commenting on the rtds part. On Thu, Jan 26, 2017 at 11:52 AM, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote: > Scheduling information debug dump for Credit2 is hard > to read as it contains the same information repeated > multiple time in different ways. > > In fact, in Credit2, CPUs are grouped in runqueus. > Here's the current debug output: > > CPU[00] sibling=00000000,00000003, core=00000000,000000ff > run: [32767.0] flags=0 cpu=0 credit=-1073741824 [w=0] load=0 (~0%) > 1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%) > 2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%) > CPU[01] sibling=00000000,00000003, core=00000000,000000ff > run: [32767.1] flags=0 cpu=1 credit=-1073741824 [w=0] load=0 (~0%) > 1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%) > 2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%) > CPU[02] sibling=00000000,0000000c, core=00000000,000000ff > run: [0.2] flags=2 cpu=2 credit=3556909 [w=256] load=262144 (~100%) > 1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%) > 2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%) > > Here, CPUs 0, 1 and 2, are all part of runqueue 0, > the content of which (which, BTW, is d0v3 and d0v4) > is printed 3 times! It is also not very useful to > see the details of the idle vcpus, as they're always > the same (except for the vCPU ids). > > With this change, we print: > - pCPUs details and, for non idle ones, what vCPU > they're running; > - the runqueue content, once and for all. > > Runqueue 0: > CPU[00] runq=0, sibling=00000000,00000003, core=00000000,000000ff > run: [0.15] flags=2 cpu=0 credit=5804742 [w=256] load=3655 (~1%) > CPU[01] runq=0, sibling=00000000,00000003, core=00000000,000000ff > CPU[02] runq=0, sibling=00000000,0000000c, core=00000000,000000ff > run: [0.3] flags=2 cpu=2 credit=6674856 [w=256] load=262144 (~100%) > CPU[03] runq=0, sibling=00000000,0000000c, core=00000000,000000ff > RUNQ: What is the difference between RUNQ and Runqueue 0 in the message? > 0: [0.1] flags=0 cpu=2 credit=6561215 [w=256] load=262144 (~100%) > 1: [0.2] flags=0 cpu=2 credit=5812356 [w=256] load=262144 (~100%) > > Stop printing details of idle vCPUs also in Credit1 > and RTDS (they're pretty useless in there too). > > Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> > --- > Cc: George Dunlap <george.dunlap@xxxxxxxxxxxxx> > Cc: Anshul Makkar <anshul.makkar@xxxxxxxxxx> > Cc: Meng Xu <mengxu@xxxxxxxxxxxxx> > --- > xen/common/sched_credit.c | 6 ++-- > xen/common/sched_credit2.c | 72 > +++++++++++++++++++++----------------------- > xen/common/sched_rt.c | 9 +++++- > xen/common/schedule.c | 7 ++-- > 4 files changed, 49 insertions(+), 45 deletions(-) > > diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c > index 24b4b22..f2d979c 100644 > --- a/xen/common/sched_rt.c > +++ b/xen/common/sched_rt.c > @@ -320,10 +320,17 @@ static void > rt_dump_pcpu(const struct scheduler *ops, int cpu) > { > struct rt_private *prv = rt_priv(ops); > + struct rt_vcpu *svc; > unsigned long flags; > > spin_lock_irqsave(&prv->lock, flags); > - rt_dump_vcpu(ops, rt_vcpu(curr_on_cpu(cpu))); > + printk("CPU[%02d]\n", cpu); We probably do not need this printk(). In rt_dump_vcpu(), we will print out the CPU number. > + /* current VCPU (nothing to say if that's the idle vcpu). */ > + svc = rt_vcpu(curr_on_cpu(cpu)); > + if ( svc && !is_idle_vcpu(svc->vcpu) ) > + { > + rt_dump_vcpu(ops, svc); > + } Maybe it is better to print the CPU number if the CPU is running an idle VCPU. The printk info could be: printk("CPU[%02d]: idle\n", cpu); > spin_unlock_irqrestore(&prv->lock, flags); > } Thanks, Meng ------------ Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |