[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

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


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.

Does it sound reasonable to you?


> Jan

Xen-devel mailing list



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