On Thu, Mar 26, 2015 at 12:48:13AM -0400, Wei Huang wrote: > Current libvirt can only handle up to 1024 thread siblings when it > reads Linux sysfs topology/thread_siblings. This isn't enough for > Linux distributions that support a large value. This patch fixes > the problem by using VIR_ALLOC()/VIR_FREE(), instead of using a > fixed-size (1024) local char array. In the meanwhile > SYSFS_THREAD_SIBLINGS_LIST_LENGTH_MAX is increased to 8192 which > should be large enough for a foreseeable future. > > Signed-off-by: Wei Huang <wei@xxxxxxxxxx> > --- > src/nodeinfo.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/src/nodeinfo.c b/src/nodeinfo.c > index 34d27a6..66dc7ef 100644 > --- a/src/nodeinfo.c > +++ b/src/nodeinfo.c > @@ -287,7 +287,7 @@ freebsdNodeGetMemoryStats(virNodeMemoryStatsPtr params, > # define PROCSTAT_PATH "/proc/stat" > # define MEMINFO_PATH "/proc/meminfo" > # define SYSFS_MEMORY_SHARED_PATH "/sys/kernel/mm/ksm" > -# define SYSFS_THREAD_SIBLINGS_LIST_LENGTH_MAX 1024 > +# define SYSFS_THREAD_SIBLINGS_LIST_LENGTH_MAX 8192 There is thread_siblings_list, which contains a range: 22-23 and thread_siblings file has all the bits set: 00c00000 For the second one, the 1024-byte buffer should be enough for 16368 possible siblings. For the first one, the results depend on the topology - if the sibling ranges are contiguous, even million CPUs should fit there. For the worst case, when every other cpu is a sibling, the second file is more space-efficient. I'm OK with using the same limit for both (8k seems sufficiently large), but I would like to know: Which one is the file that failed to parse in your case? I think both virNodeCountThreadSiblings and virNodeGetSiblingsList could be rewritten to share some code and only look at one of the sysfs files. The question is - which one? Jan
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list