From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v3 01/19] xen: dump vNUMA information with
 debug key "u"
Date: Wed, 14 Jan 2015 11:45:25 +0000
Message-ID: <54B656D5.1090007@citrix.com>
References: <1421151107-20842-1-git-send-email-wei.liu2@citrix.com>
	<1421151107-20842-2-git-send-email-wei.liu2@citrix.com>
	<54B5704B.1010805@citrix.com>
	<20150113205151.GB17391@zion.uk.xensource.com>
	<54B64DA4.2080900@citrix.com>
	<54B65FEC0200007800054BDD@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <54B65FEC0200007800054BDD@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Cc: dario.faggioli@citrix.com, Elena Ufimsteva <ufimtseva@gmail.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On 14/01/15 11:24, Jan Beulich wrote:
>>>> On 14.01.15 at 12:06, <andrew.cooper3@citrix.com> wrote:
>> May I suggest the following sylistic changes:
>>
>> 2 vnodes, 20 vcpus:
>>   1: pnode 0, vcpus {1-9}
>>     0000000000000000 - 000000005dc00000
>>   2: pnode 1, vcpus {10-20}
>>     000000005dc00000 - 00000000bb000000
>>     0000000100000000 - 0000000100800000
>>  
>> You have already stated 2 vnodes, so "vnode $X" is redundant as the list
>> index.  The vcpus are exceedingly likely to be consecutively allocated,
>> and cpumask_scnprintf() is a very concise way of representing them (and
>> will reduce your code quite a bit).
> You mean bitmap_scnprintf() - cpumask_scnprintf() is not suitable for
> dealing with vCPU-s.

Yes, although I was actually thinking of the scnlistprintf() variant.

However, I further notice that the source data is not in an appropriate
form, so it is perhaps a less sensible suggestion.

~Andrew