[libvirt] [PATCH 4/5] capabilities: Switch CPU data in NUMA topology to a struct

Peter Krempa pkrempa at redhat.com
Mon Jan 21 13:10:17 UTC 2013


On 01/21/13 12:31, Martin Kletzander wrote:
> On 01/19/2013 12:06 AM, Peter Krempa wrote:
>> This will allow storing additional topology data in the NUMA topology
>> definition.
>>
>> This patch changes the storage type and fixes fallback of the change
>> across the drivers using it.
>>
>> This patch also changes semantics of adding new NUMA cell information.
>> Until now the data were re-allocated and copied to the topology
>> definition. This patch changes the addition function to steal the
>> pointer to a pre-allocated structure to simplify the code.
>> ---
>>   src/conf/capabilities.c | 29 ++++++++++++++++++-----------
>>   src/conf/capabilities.h | 14 ++++++++++++--
>>   src/nodeinfo.c          | 22 ++++++++++++----------
>>   src/qemu/qemu_process.c |  2 +-
>>   src/test/test_driver.c  | 15 ++++++++++++---
>>   src/xen/xend_internal.c | 24 +++++++++++++-----------
>>   6 files changed, 68 insertions(+), 38 deletions(-)
>>
>
> [...]
>
>> diff --git a/src/conf/capabilities.h b/src/conf/capabilities.h
>> index 19b99c6..124d8c1 100644
>> --- a/src/conf/capabilities.h
>> +++ b/src/conf/capabilities.h
>> @@ -84,12 +84,21 @@ struct _virCapsGuest {
>>       virCapsGuestFeaturePtr *features;
>>   };
>>
>> +typedef struct _virCapsHostNUMACellCPU virCapsHostNUMACellCPU;
>> +typedef virCapsHostNUMACellCPU *virCapsHostNUMACellCPUPtr;
>> +struct _virCapsHostNUMACellCPU {
>> +    int id;
>> +    int socket_id;
>> +    int core_id;
>> +    char *siblings_list;
>
> We don't actually need this for anything right now, but it would be nice
> to have it stored in virBitmap in case we'll want to work with it in the
> future.
>
> [...]
>
>> diff --git a/src/nodeinfo.c b/src/nodeinfo.c
>> index 477104f..dffe7d1 100644
>> --- a/src/nodeinfo.c
>> +++ b/src/nodeinfo.c
>> @@ -79,9 +79,11 @@ freebsdNodeGetCPUCount(void)
>>   #ifdef __linux__
>>   # define CPUINFO_PATH "/proc/cpuinfo"
>>   # define SYSFS_SYSTEM_PATH "/sys/devices/system"
>> +# define SYSFS_CPU_PATH SYSFS_SYSTEM_PATH"/cpu"
>
> s/PATH"/PATH "/
>
>>   # define PROCSTAT_PATH "/proc/stat"
>>   # define MEMINFO_PATH "/proc/meminfo"
>>   # define SYSFS_MEMORY_SHARED_PATH "/sys/kernel/mm/ksm"
>> +# define SYSFS_THREAD_SIBLINGS_LIST_LENGHT_MAX 1024
>>
>>   # define LINUX_NB_CPU_STATS 4
>>   # define LINUX_NB_MEMORY_STATS_ALL 4
>> @@ -1476,9 +1478,10 @@ nodeCapsInitNUMA(virCapsPtr caps)
>>       int n;
>>       unsigned long *mask = NULL;
>>       unsigned long *allonesmask = NULL;
>> -    int *cpus = NULL;
>> +    virCapsHostNUMACellCPUPtr cpus = NULL;
>>       int ret = -1;
>>       int max_n_cpus = NUMA_MAX_N_CPUS;
>> +    int ncpus = 0;
>>
>>       if (numa_available() < 0)
>>           return 0;
>> @@ -1492,7 +1495,6 @@ nodeCapsInitNUMA(virCapsPtr caps)
>>
>>       for (n = 0 ; n <= numa_max_node() ; n++) {
>>           int i;
>> -        int ncpus;
>>           /* The first time this returns -1, ENOENT if node doesn't exist... */
>>           if (numa_node_to_cpus(n, mask, mask_n_bytes) < 0) {
>>               VIR_WARN("NUMA topology for cell %d of %d not available, ignoring",
>> @@ -1515,21 +1517,21 @@ nodeCapsInitNUMA(virCapsPtr caps)
>>
>>           for (ncpus = 0, i = 0 ; i < max_n_cpus ; i++)
>>               if (MASK_CPU_ISSET(mask, i))
>> -                cpus[ncpus++] = i;
>> +                cpus[ncpus++].id = i;
>>
>> -        if (virCapabilitiesAddHostNUMACell(caps,
>> -                                           n,
>> -                                           ncpus,
>> -                                           cpus) < 0)
>> +        if (virCapabilitiesAddHostNUMACell(caps, n, ncpus, cpus) < 0)
>>               goto cleanup;
>> -
>> -        VIR_FREE(cpus);
>> +        cpus = NULL;
>
> I generally don't like stealing pointers because of similar
> contraptions.  Even though it is clear from memory allocation POV and it
> saves a lot of allocations in this case, it's a bit harder to read IMHO.

Well, yeah, it might be harder to read, but I wanted to avoid doing a 
deep copy on each iteration. And the callers of this function freed the 
original array anyways so I think it was really a waste of operations.

>
> Being the devil's advocate, I must say I'd be nice to have the tests for
> this since you've started modifying the test driver.  Also documentation
> for all the new information should be added into
> 'docs/formatcaps.html.in' with some explanation.

I'm planing on adding docs and tests, but I was waiting for a review to 
settle the format before doing so. (And I forgot to write about that)

>
> Xen part of this patch looks OK, although I don't have any XEN machine
> to try it on.
>
> Because this and [PATCH 5/5] both require [PATCH 3/5] to be in, I'm
> cond-ACKing this patch with the same condition as [PATCH 3/5].

I assume that you mean patch 2/5 :)

>
> Martin
>




More information about the libvir-list mailing list