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

Re: [Xen-devel][PATCH] libxc bitmap utils and vcpu-affinity


  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: Dulloor <dulloor@xxxxxxxxx>
  • Date: Tue, 30 Mar 2010 12:05:37 -0400
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
  • Delivery-date: Tue, 30 Mar 2010 09:07:08 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=S+areULzWg81fAjFiFDu0zWODFXGhXWJsHmNS8aYp6xvxqAnN46bx+5+YNMwAvUbJr Wg7oCiedKJy7PVf8hKb0iVt556sfznkGWPUqTBL6iIpiRRTFkmKQwEzg8Q3oXCiUliyI 40UyeHpKsYupOw7y09BikHNOQk5fpJGQfJe58=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

> No changeset comment. No signed-off-by line.
Sorry, I forgot. Will do once we finalize on the patch.

> It actually bloats the libraries by a net 650 LOC
> (747 added, 87 deleted according to diffstat).
In the patch, we have used the library only for vcpu get/set affinity.
There are clearly other opportunities (right now and in future) to use
most of the functions provided by the library, which will offset this.
Also, this provides a cleaner/standard way of using the cpumap
structure in libxc.

> And below I append the very first function I read: it doesn't inspire
> confidence that the implementation is over-complicated/long and
> unnecessarily handles 16-bit values.
I guess you mean 8-bit values. The library works with byte-based
bitmap structures, instead of "uint32_t or uint64_t" bitmap
structures, so that we don't need to convert when using the
bitmap-library with xenctl_cpumap. Please let know if you would rather
that we keep the bitmap utilities separate from xenctl_cpumap and
provide for conversion functions. That would be a small change.

The function that you quote is inspired from linux kernel
implementation (as mentioned) and is a simple generic function. And I
have tested the library thoroughly.

> Why should I show your patch some love?
We can work towards that ;)

-dulloor

On Tue, Mar 30, 2010 at 11:16 AM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> No changeset comment. No signed-off-by line. It actually bloats the
> libraries by a net 650 LOC (747 added, 87 deleted according to diffstat).
> And below I append the very first function I read: it doesn't inspire
> confidence that the implementation is over-complicated/long and
> unnecessarily handles 16-bit values. Why should I show your patch some love?
>
>  -- Keir
>
> +static inline int __xc_ffs(uint8_t byte)
> +{
> +       int num = 0;
> +
> +       if ((byte & 0xff) == 0) {
> +               num += 8;
> +               byte >>= 8;
> +       }
> +       if ((byte & 0xf) == 0) {
> +               num += 4;
> +               byte >>= 4;
> +       }
> +       if ((byte & 0x3) == 0) {
> +               num += 2;
> +               byte >>= 2;
> +       }
> +       if ((byte & 0x1) == 0)
> +               num += 1;
> +       return num;
> +}
>
> On 30/03/2010 15:42, "Dulloor" <dulloor@xxxxxxxxx> wrote:
>
>> Resubmitting the patch.
>>
>> -dulloor
>>
>> ---------- Forwarded message ----------
>> From: Dulloor <dulloor@xxxxxxxxx>
>> Date: Tue, Mar 23, 2010 at 12:55 PM
>> Subject: Re: [Xen-devel][PATCH] libxc bitmap utils and vcpu-affinity
>> To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
>> Cc: Jan Beulich <JBeulich@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx"
>> <xen-devel@xxxxxxxxxxxxxxxxxxx>
>>
>>
>> Please use this patch, in which length of bitmap is
>> (physinfo.max_cpu_id+1), rather than (physinfo.nr_cpus).
>>
>> -dulloor
>>
>> On Tue, Mar 23, 2010 at 12:41 PM, Dulloor <dulloor@xxxxxxxxx> wrote:
>>> I meant utils for **xenctl_cpumap**
>>>
>>> On Tue, Mar 23, 2010 at 12:40 PM, Dulloor <dulloor@xxxxxxxxx> wrote:
>>>> Fine, I agree with you both. Attached is a patch adding utils for
>>>> xenctl_bitmap (to libxc) and using the same in vcpu_(get|set)affinity.
>>>> For the guest-numa interface, I will see if I can use xenctl_cpumap.
>>>>
>>>> -dulloor
>>>>
>>>> On Tue, Mar 23, 2010 at 7:05 AM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
>>>> wrote:
>>>>> On 23/03/2010 10:10, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>>>>
>>>>>>>>> Dulloor <dulloor@xxxxxxxxx> 22.03.10 18:44 >>>
>>>>>>> Motivation for using xenctl_cpumask in Xen interfaces :
>>>>>>> - xenctl_cpumap is just 4 bytes smaller than static xenctl_cpumask for
>>>>>>> 128 cpus (128 would be good for quite some time). However, the new
>>>>>>
>>>>>> I don't buy this (we're already building for 256 CPUs, looking forward
>>>>>> to further bump this in the not too distant future), and I'm generally
>>>>>> opposed to introducing hard coded limits in a public interface.
>>>>>
>>>>> We should use xenctl_cpumask everywhere for specifying physical CPU
>>>>> bitmaps,
>>>>> even into guest NUMA interfaces if appropriate. I don't really care if it
>>>>> is
>>>>> a bit harder to use than a static bitmap.
>>>>>
>>>>>  -- Keir
>>>>>
>>>>>
>>>>>
>>>>
>>>
>
>
>

_______________________________________________
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®.