[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 4/7] x86: collect CQM information from all sockets



>>> On 28.01.14 at 16:15, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >>> On 28.01.14 at 15:34, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> > On 28/01/14 14:23, Xu, Dongxiao wrote:
>> >>> And finally, I think the total size of the buffer here can easily
>> >>> exceed a page, i.e. this then ends up being a non-order-0
>> >>> allocation, which may _never_ succeed (i.e. the operation is
>> >>> then rendered useless). I guest it'd be better to e.g. vmap()
>> >>> the MFNs underlying the guest buffer.
>> >> Do you mean we check the size of the total size, and allocate MFNs one by
>> > one, then vmap them?
>> >
>> > I still think this is barking mad as a method of getting this quantity
>> > of data from Xen to the toolstack in a repeated fashon.
>> >
>> > Xen should allocate a per-socket buffer at the start of day (or perhaps
>> > on first use of CQM), and the CQM monitoring tool gets to map those
>> > per-socket buffers read-only.
>> >
>> > This way, all processing of the CQM data happens in dom0 userspace, not
>> > in Xen in hypercall context; All Xen has to do is periodically dump the
>> > MSRs into the pages.
>> 
>> Indeed - if the nature of the data is such that it can be exposed
>> read-only to suitably privileged entities, then this would be the
>> much better interface.
> 
> If the data fetching is not hypercall driven, do you have a recommendation 
> on how frequent Xen dumps the MSRs into the share page?

Perhaps an "update the shared pages" hypercall should be made
then prior to reading the shared space?

Jan


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


 


Rackspace

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