From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] libxc bitmap utils and vcpu-affinity Date: Tue, 30 Mar 2010 16:16:22 +0100 Message-ID: References: <940bcfd21003300742s28db15dbm9bf3316f8625f180@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <940bcfd21003300742s28db15dbm9bf3316f8625f180@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dulloor , "xen-devel@lists.xensource.com" Cc: Jan Beulich List-Id: xen-devel@lists.xenproject.org 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 =3D 0; + + if ((byte & 0xff) =3D=3D 0) { + num +=3D 8; + byte >>=3D 8; + } + if ((byte & 0xf) =3D=3D 0) { + num +=3D 4; + byte >>=3D 4; + } + if ((byte & 0x3) =3D=3D 0) { + num +=3D 2; + byte >>=3D 2; + } + if ((byte & 0x1) =3D=3D 0) + num +=3D 1; + return num; +} On 30/03/2010 15:42, "Dulloor" wrote: > Resubmitting the patch. >=20 > -dulloor >=20 > ---------- Forwarded message ---------- > From: Dulloor > Date: Tue, Mar 23, 2010 at 12:55 PM > Subject: Re: [Xen-devel][PATCH] libxc bitmap utils and vcpu-affinity > To: Keir Fraser > Cc: Jan Beulich , "xen-devel@lists.xensource.com" > >=20 >=20 > Please use this patch, in which length of bitmap is > (physinfo.max_cpu_id+1), rather than (physinfo.nr_cpus). >=20 > -dulloor >=20 > On Tue, Mar 23, 2010 at 12:41 PM, Dulloor wrote: >> I meant utils for **xenctl_cpumap** >>=20 >> On Tue, Mar 23, 2010 at 12:40 PM, Dulloor 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. >>>=20 >>> -dulloor >>>=20 >>> On Tue, Mar 23, 2010 at 7:05 AM, Keir Fraser >>> wrote: >>>> On 23/03/2010 10:10, "Jan Beulich" wrote: >>>>=20 >>>>>>>> Dulloor 22.03.10 18:44 >>> >>>>>> Motivation for using xenctl_cpumask in Xen interfaces : >>>>>> - xenctl_cpumap is just 4 bytes smaller than static xenctl_cpumask f= or >>>>>> 128 cpus (128 would be good for quite some time). However, the new >>>>>=20 >>>>> I don't buy this (we're already building for 256 CPUs, looking forwar= d >>>>> to further bump this in the not too distant future), and I'm generall= y >>>>> opposed to introducing hard coded limits in a public interface. >>>>=20 >>>> 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. >>>>=20 >>>> =A0-- Keir >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20