[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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.