[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RESEND 11/12] xl: numa-sched: enable getting/specifying per-vcpu node-affinity
On gio, 2013-11-07 at 18:33 +0000, Ian Jackson wrote: > Dario Faggioli writes ("[PATCH RESEND 11/12] xl: numa-sched: enable > getting/specifying per-vcpu node-affinity"): > > by showing it, upon request ('-n' switch), as a part of the > > output of `xl vcpu-list'. Such output looks like this: > ... > > # xl vcpu-list -n > > > > Name ID VCPU CPU State Time(s) CPU Affinity / NUMA Affinity > > Domain-0 0 0 8 -b- 4.4 any cpu / any node > > Domain-0 0 1 0 -b- 1.2 any cpu / any node > > vm-test 1 0 8 -b- 2.4 any cpu / 1 > > vm-test 1 1 13 -b- 3.3 any cpu / 1 > > > > The "vcpu-pinning / vcpu-affinity" part may indeed look > > weird, as it is different from the other fields. > > Unfortunately, it's very hard to properly format it in > > columns, since there is no such things as minimal or > > maximal lengths for the bitmaps being printed. > > Can you use the same syntax for printing as would be legal in > the config file ? > That is actually what is happening, for single cpu/node bitmaps. The problem arises when I need to print two bitmaps, one next to the other, like the cpumap for vCPU affinity and the nodemap for NUMA affinity above. The thing is I don't think there is a maximal length for the strings representing the bitmaps being printed, and this no easy way to format the last two values (again "CPU Affinity" and "NUMA Affinity") above in columns... Hence the "/". Ideas? (BTW, the new version of the series I'm preparing will be very different, considering we decided with George and Jan to change the fundamental architecture of the whole thing. However, there still may be the need to doing something like the above, independently whether it will be for printing hard and soft affinity, instead than CPU and NUMA affinity.) > > While at it, the implementation of `xl vcpu-list' is reworked > > a little bit, making it more similar to the one of `xl list' > > and more compliant with the libxl programming paradigm (e.g., > > regarding allocating at the beginning and freeing on exit). > > Can you do this in a pre-patch ? > Ok. > > xl manual page is updated accordingly. > > > -static int update_cpumap_range(const char *str, libxl_bitmap *cpumap) > > +static int update_bitmap_range(const char *str, libxl_bitmap *bitmap) > > I don't understand how this set of changes relates to this patch. > Well, I need to parse strings that may be very similar (the usual "1,2-7,^4" stuff), but with potentially different meaning for the various substrings (pcpus vs. nodes). Anyway, in case I'm keeping this, or doing something similar to this for the new series, I'll try to figure out a way to make it more simple, or at minimum more readable and clarify why it is needed (by breaking the patch down, etc.). Thanks and Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |