[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v9 1/6] x86: detect and initialize Cache QoS Monitoring feature
>>> On 03.03.14 at 14:21, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote: >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] >> >>> On 19.02.14 at 07:32, Dongxiao Xu <dongxiao.xu@xxxxxxxxx> wrote: >> > + /* Allocate CQM buffer size in initialization stage */ >> > + cqm_pages = ((cqm->max_rmid + 1) * sizeof(domid_t) + >> > + (cqm->max_rmid + 1) * sizeof(uint64_t) * NR_CPUS)/ >> >> Does this really need to be NR_CPUS (rather than nr_cpu_ids)? > > Okay. > As you mentioned in later comment, the CQM data is indexed per-socket. > Here we use NR_CPUS or nr_cpu_ids because it is big enough to cover the > possible socket number in the system (even consider hotplug case). > Is there a better way that we can get the system socket number (including > the case even there is no CPU in that socket)? I think we should at least get the estimation as close as possible: Count the sockets that we know of (i.e. that have at least one core/thread) and add the number of "disabled" (hot-pluggable) CPUs if ACPI doesn't surface enough information to associate them with a socket (but I think MADT provides all the needed data). >> > + PAGE_SIZE + 1; >> > + cqm->buffer_size = cqm_pages * PAGE_SIZE; >> > + >> > + cqm->buffer = >> alloc_xenheap_pages(get_order_from_pages(cqm_pages), 0); >> >> And does the allocation really need to be physically contiguous? >> If so - did you calculate how much more memory you allocate >> (due to the rounding up to the next power of 2), to decide >> whether it's worthwhile freeing the unused portion? > > The buffer needs to be contiguous since userspace will map it as read-only to > avoid data copy. That's not an argument for other that coding simplicity - user space could equally well map an array of dis-contiguous MFNs. > According to my rough calculation, the cqm_pages value is about 29 pages on > my test machine. Your test machine doesn't count; what counts is the maximum possible with the currently enforced limits. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |