All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>,
	xen-devel@lists.xenproject.org
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Anshul Makkar <anshul.makkar@citrix.com>,
	Meng Xu <mengxu@cis.upenn.edu>
Subject: Re: [PATCH] xen: sched: improve debug dump output.
Date: Wed, 1 Feb 2017 14:59:42 +0000	[thread overview]
Message-ID: <2d136d04-5afb-ae77-e556-bdfeb49b2dc0@citrix.com> (raw)
In-Reply-To: <148544957013.26566.1886390191777485188.stgit@Solace.fritz.box>

On 26/01/17 16:52, Dario Faggioli 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:
>       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@citrix.com>

Hang on -- how does this relate to the credit2 dumping patch you sent
the previous week?

I'm all in favor of not saving up a massive queue of patches, but if the
patches have conflicts with existing patches, I think it would be better
if you re-sent a full series with a new version number, so I wouldn't
have to try to figure out what order they needed to be applied in and
which ones weren't necessary anymore.  There's no problem, I don't
think, of sending version n+1 of a series that has no changes other than
adding new patches.

I've checked in and pushed the three patches that I reviewed today; can
you rebase your outstanding changes and send another series?

Thanks!  And sorry it took so long to get to.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-02-01 14:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-26 16:52 [PATCH] xen: sched: improve debug dump output Dario Faggioli
2017-01-26 18:59 ` Meng Xu
2017-01-26 22:08   ` Dario Faggioli
2017-01-27 17:05     ` Meng Xu
2017-01-27 18:36       ` Dario Faggioli
2017-01-27 19:26         ` Meng Xu
2017-01-27 19:28 ` Meng Xu
2017-02-01 14:59 ` George Dunlap [this message]
2017-02-02 16:59   ` Dario Faggioli

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 \
    --in-reply-to=2d136d04-5afb-ae77-e556-bdfeb49b2dc0@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=anshul.makkar@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=mengxu@cis.upenn.edu \
    --cc=xen-devel@lists.xenproject.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.