[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
  • 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
  • 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;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 09/16/10 12:45, Ian Campbell wrote:
On Wed, 2010-09-15 at 08:26 +0100, Juergen Gross wrote:
Hi,

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

Thanks!

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
name?

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)),

Okay.

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 *
sizeof(*....map)",

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

--
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.