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

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



On 05/19/2014 12:45 PM, Jan Beulich wrote:
On 19.05.14 at 13:28, <George.Dunlap@xxxxxxxxxxxxx> wrote:
But in reality, all we need the daemon for is a place to store the
information to query.  The idea we came up with was to allocate memory
*inside the hypervisor* to store the information.  The idea is that
we'd have a sysctl to prompt Xen to *collect* the data into some
memory buffers inside of Xen, and then a domctl that would allow you
query the data on a per-domain basis.

That should be a good balance -- it's not quite as good as having as
separate daemon, but it's a pretty good compromise.
Which all leaves aside the suggested alternative of making available
a couple of simple operations allowing an eventual daemon to do the
MSR accesses without the hypervisor being concerned about where
to store the data and how to make it accessible to the consumer.

From a libxl perspective, if we provide "libxl_qos_refresh()" (or "libxl_qos_freshness_set()") and "libxl_qos_domain_query()" (or something like it), it doesn't matter whether it's backed by memory stored in Xen via hypercall or by a daemon.

What I was actually envisioning was an option to either query them by a domctl hypercall, or by having a daemon map the pages and read them directly. That way we have the daemon available for those who want it (say, maybe xapi, or a future libxl daemon / stat collector), but we can get a basic level implemented right now without a terrible amount of architectural work.

There are a couple of options regarding collecting the data.  One is
to simply require the caller to do a "poll" sysctl every time they
want to refresh the data.  Another possibility would be to have a
sysctl "freshness" knob: you could say, "Please make sure the data is
no more than 1000ms old"; Xen could then automatically do a refresh
when necessary.

The advantage of the "poll" method is that you could get a consistent
snapshot across all domains; but you'd have to add in code to do the
refresh.  (An xl command querying an individual domain would
undoubtedly end up calling the poll on each execution, for instance.)

An advantage of the "freshness" knob, on the other hand, is that you
automatically get coalescing without having to do anything special
with the interface.
With the clear disadvantage of potentially doing work the results of
which is never going to be looked at by anyone.

Jan, when you make a criticism it needs to be clear what alternate you are suggesting.

AFAICT, regarding "collection" of the data, we have exactly three options:
A. Implement a "collect for all domains" option (with an additional "query data for a single domain" mechanism; either by daemon or hypercall).
B. Implement a "collect information for a single domain at a time" option
C. Implement both options.

"Doing work that is never looked at by anyone" will always be a potential problem if we choose A, whether we use a daemon, or use the polling method, or use the automatic "freshness" knob. The only way to avoid that is to do B or C.

We've already said that we expect the common case we expect is for a toolstack to want to query all domains anyway. If we think that's true, "make the common case fast and the uncommon case correct" would dictate against B.

So are you suggesting B (disputing the expected use case)? Or are you suggesting C? Or are you just finding fault without thinking things through?

 -George

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