Re: [Xen-devel] [PATCH v9 1/6] x86: detect and initialize Cache QoS Monitoring feature

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.03.14 at 11:46, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >>> On 18.03.14 at 11:15, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote:
>> > By using dynamic memory allocation and data sharing mechanism, we may need
>> > two hypercalls when Dom0 tool stack is querying CQM related info.
>> >  - 1st hypercall is to let Xen allocate the memory and put CQM data there.
>> >  - 2nd hypercall is to indicate Dom0 tool stack already digested the CQM 
>> > data
>> > and Xen can free the memory.
>> 
>> Why would that memory ever need de-allocating?
>> 
>> Anyway, could you clarify again what amount of data we're
>> talking about, without me having to dig out the old patch series?
> 
> Originally we statically allocate memory in initialization time, and the 
> size is "rmid_max * socket_max", which may be a very big value. As the 
> propose in today's first mail, we can use the dynamic memory allocation as 
> "rmid_inuse * socket_inuse" for CQM related pages when user is really issuing 
> query operations, this can save the allocated memory size, because at that 
> point, we know the exact socket number in the system and exact the in use 
> RMID, and no need to predict them as maximum values.

That wasn't my question. The question (tailored to the above
description of yours) is - what are reasonable values of rmid_inuse
and socket_inuse on a huge system?

> Back to the above question why memory need de-allocating:
> Since the rmid_inuse and socket_inuse may be changing from time to time, the 
> allocating memory size will be different. Therefore we need to allocate them 
> when user issues the hypercall, and then free them after the data digest is 
> finished.

But once we have topology information in hand, deriving the
maximum possible socket number from MADT data ought to be
possible. Hence the allocation could be done with the maximum
size. An alternative (allowing the allocated size to be limited to
in-use resources) might be to do the de-allocation during CPU
hotplug rather than upon explicit Dom0 request.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel