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:15, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Tuesday, March 18, 2014 6:09 PM
>> To: Xu, Dongxiao
>> Cc: andrew.cooper3@xxxxxxxxxx; Ian.Campbell@xxxxxxxxxx;
>> Ian.Jackson@xxxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx;
>> xen-devel@xxxxxxxxxxxxx; konrad.wilk@xxxxxxxxxx; dgdegra@xxxxxxxxxxxxx;
>> keir@xxxxxxx 
>> Subject: RE: [PATCH v9 1/6] x86: detect and initialize Cache QoS Monitoring
>> feature
>> 
>> >>> On 18.03.14 at 11:02, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote:
>> > Previously due to the large amount of data, we use the method to let Xen
>> > share the CQM pages to Dom0 in read only way to avoid data copy.
>> > However since the data amount is reduced a lot with above approach, do you
>> > think whether we still need to use this share way? Or like most of the 
> other
>> > sysctl/domctl (e.g., xl list) command, which uses copy_to_guest() to pass 
> the
>> > data?
>> 
>> Iirc we're talking about a square table with each dimension being the
>> socket count. Considering an 8-node 4-socket system, that would
>> still be 1024 entries, i.e. exceeding a page in size. Hence I would
>> think that the read-only sharing approach might still be better. Of
>> course, if the data amount was smaller (and by so much that even
>> on huge systems it's no more than a page), that would be different.
> 
> Okay.
> 
> 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?

Jan


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