Re: [Xen-devel] Xen Platform QoS design discussion

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> 05/30/14 3:07 AM >>>
>> While I can see the use and attraction of a generic MSR access
>> hypercalls, using this method for getting QoS data is going to have
>> subsantitally higher overhead than even the original domctl suggestion.
>> 
>> I do not believe it will be an effective means of getting large
>> quantities of data from ring0 MSRs into dom0 userspace.  This is not to
>> say that having a generic MSR interface is a bad thing, but I don't
>> think it should be used for this purpose.
>
>They are the two directions to implement this feature:
>
>Generic MSR access hypercall: It removes most of the policy in hypervisor
> and put them in Dom0 userspace, which makes the implementation in
> hypervisor very simple, with slightly higher cost (more hypercalls).
>Sysctl hypercall: Hypervisor needs to consolidate all the CQM data which
> burdens the implementation, with more memory allocation, data sharing
> mechanism (2-level, page's address page, and page itself), also more
> policies in hypervisor, etc. While its cost is slightly less.

>In my opinion, domctl is a compromise between two approaches, with
> moderate policies in hypervisor, moderate size of memory allocation, with
> moderate cost.

>I would prefer domctl or generic MSR access way, which makes the
> implementation in hypervisor simple enough, but with only slightly higher 
> cost.

Andrew and I talked a little more about this yesterday, and I think we agreed
that until there is a proven need for the sysctl and/or the domctl approach, the
generic MSR access route should be good enough. Suitably batched the
number of hypercalls doesn't even need to be much higher than either of the
other approaches.

Question is whether this mechanism (which I'd like to be done so it can also
later get added support for e.g. port I/O: see Linux'es dcdbas_smi_request()
for where this might be useful) should become a sysctl op or - to be
easily usable by the kernel too - a platform one.

Jan


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