> I'm missing the motivation for this. It sounds less good than what we have
> already.
xenctl_cpumap is dynamic and could work for any size, but there are
many reasons for adding xenctl_cpumask.
Motivation for new data type and bitmap utils in libxc :
- xenctl_cpumask is a simple and useful data type in xen-tools. We
deal with cpumasks at several places and the need increases with numa
(for instance, node selection with guest numa).
- The bitmap utils in the patch could work with both xenctl_cpumap as
well as xenctl_cpumask structure. So, that part is independent of the
new structure. And, I can just submit that part alone, if we decide to
stay with xenctl_cpumap.
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
data type cleans up the code considerably, as you can see from its use
in vcpu_(set|get)affinity - no need to read physinfo, lock pages
separately, etc.
- Maintaining the size of xenctl_cpumask consistent between xen and
xen-tools is simple. And, conversion between xenctl_cpumask and
cpumask inside xen is simple too (not much different from before).
- There are other interfaces where xenctl_cpumask could be used. For
pv guest numa, I pass cpumasks in the start-info and the structure
needs to be static. The size of the structure is kept consistent
through a numa-interface version.
-dulloor
On Mon, Mar 22, 2010 at 3:30 AM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> On 22/03/2010 03:33, "Dulloor" <dulloor@xxxxxxxxx> wrote:
>
>> This patch adds :
>>
>> * A byte-based cpumask type(xenctl_cpumask) for setting vcpu-affinity
>> as well as numa-node-affinity, etc in libxc.
>>
>> * Add common bitmap utils to libxc, which can be used both for
>> xenctl_cpumask (and with small changes for xenctl_cpumap, if desired),
>> so that we can do common operations on cpumask easily.
>>
>> As opposed to xenctl_cpumap, xenctl_cpumask is a static structure
>> (just 4 bytes larger for 128 cpus), but keeps the interface/code
>> cleaner. The domctl_interface version keeps the size of xenctl_cpumask
>> consistent between xen and xen-tools.
>
> I'm missing the motivation for this. It sounds less good than what we have
> already.
>
> -- Keir
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home