This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [Patch][resend] implementation of cpupool support in xl

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [Patch][resend] implementation of cpupool support in xl
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Thu, 16 Sep 2010 14:02:46 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 16 Sep 2010 05:03:51 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1284638569; x=1316174569; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; z=Message-ID:=20<4C920766.30309@xxxxxxxxxxxxxx>|Date:=20Th u,=2016=20Sep=202010=2014:02:46=20+0200|From:=20Juergen =20Gross=20<juergen.gross@xxxxxxxxxxxxxx>|MIME-Version: =201.0|To:=20Ian=20Campbell=20<Ian.Campbell@xxxxxxxxxx> |CC:=20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-devel@lists .xensource.com>|Subject:=20Re:=20[Xen-devel]=20[Patch][re send]=20implementation=20of=20cpupool=20support=0D=0A=20i n=20xl|References:=20<4C907510.3070904@xxxxxxxxxxxxxx>=20 <1284633914.16095.1572.camel@xxxxxxxxxxxxxxxxxxxxxx> |In-Reply-To:=20<1284633914.16095.1572.camel@xxxxxxxxxxxx source.com>; bh=zl2Gv1nkliYM0eqrNNbncVyNoPFYggHk0s+qRCfyAIo=; b=gmlB2NVbX6RTA34NnehQBjqo3INVMevE2H4wwv/tq1MPaM8rX1bh0lJC ljNgw7Zum1cfyEl3ATG79HreUWKrPYj4CsF4Mr6BYGq0duVAHUL8RnkNR lQSJzWW6ZTrmMepU2daXYzMLxZtFWXHrmQpQcu9pQYpUbW83LT+szINfd mmZdIk9IswudWyKFxcasM4kLPA8xbo3mU9mTQZKvkISTlsdMw1JhDq5Bq 7dtFFOE+t7SOwhWiHXngcL9+p6sGM;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=NkVpBPjTtE+oS15wL3KTi5X7aPyIt2oEAOANXDWPmqcK2Fv5r6TOL1I6 xoxIzDpBVQhkGNGkOQy19reNf4Kjt7XShaHZMNB2adPZrw6Vf1q7RkACZ 9i2lo98qYX3tRW7FR6+KUaFAI6mktGTEUeC6L7KFo82+cCDkh1858+rJn aNwyFOMFFufRSqn//DEXDbVuCvxk7sTFw03Jp9jV1CZS8WSeL4UqOP5Rv sckOOUJAzuKPx4K4l/4yvuMRdYarS;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1284633914.16095.1572.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Fujitsu Technology Solutions
References: <4C907510.3070904@xxxxxxxxxxxxxx> <1284633914.16095.1572.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100805 Iceowl/1.0b1 Icedove/3.0.6
On 09/16/10 12:45, Ian Campbell wrote:
On Wed, 2010-09-15 at 08:26 +0100, Juergen Gross wrote:

attached patch implements cpupool support in xl. Rewrite of previous patch
after rework of libxl.


Please could you provide a changelog message? It seems you needed to
modify the libxc interface in order to support libxl, it would be worth
commenting on what/why you changed.

Okay, done.

In several places I notice you calculate (X + 64) / 64. Normally I would
expect a (X + 63) / 64 pattern to round something up (for example in
other places you use + 7 / 8). Is this deliberate? Probably worth a
comment, or maybe wrap the concept into a function with an appropriate

This was the conversion from max_cpu_id (which is 1 less than the max
number of cpus) to the number of map elements. I've moved this to an own
function for allocating a cpumap.map.

I think the units of libxl_cpumap.size might be worth a comment too,
especially since appears to differ from the units used in the libxc
interface. You can do this in the IDL with e.g.
-    ("size", uint32),
+    ("size", uint32, False, "number of<bananas>  in map"),
      ("map",  Reference(uint64)),


I think<bananas>=="uint64_t sized words"? Perhaps size would be better
represented as the maximum CPU ID in the map? The fact that the map is
rounded up to the next 64 bit boundary isn't too interesting to callers,
is it?

I kept your proposal to keep the size in bytes (like in xc).

I saw a "size * 8" which I think would better as "size *

The 8 is the number of bits in a byte (size being number of bytes).

Similarly callers seem to be doing "map[i / 64]&  (i %64)" type
arithmetic, I think providing a libxl_cpumap_cpu_present helper (and
_set/_clear if necessary) would help here.

Done that, too.


Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Attachment: xl-pools.patch
Description: Text Data

Xen-devel mailing list