Re: [Xen-devel] [PATCH] xen: Implement domain runstates

[Bruce Edge <bruce.edge@xxxxxxxxx>]

On Thu, Nov 25, 2010 at 2:24 PM, Keir Fraser <keir@xxxxxxx> wrote:

On 25/11/2010 20:02, "Bruce Edge" <bruce.edge@xxxxxxxxx> wrote:

> Irrespective of the nature of the suggested functionality, I do agree that xen
> users will be more likely to try something if it's part of the default build,
> especially if the benefit is not immediately obvious. With all the complexity
> associated with any virtualization project, I think that many integrators
> don't have the time to experiment with every possible option included in the
> "off the shelf" Xen, not to mention those that require explicit patching and
> manual inclusion.
> That said I would try this as a "VCPU allocation suitability" metric for any
> xen system. The ability to see this data 'at a glance' would be beneficial to
> admins and system architects.
> A lot of data is available if you know how to get it. That is very different
> from presenting that data in an easily digestible format requiring no work to
> use.

You may be under the impression the feature is free. It isn't -- it adds a
lock and loop over all vcpus on every vcpu scheduling/descheduling decision.
That could be frequent for VCPUs doing a lot of short blocking, for example.
And the system-wide work done to support this feature will scale
quadratically on average with vcpus-per-domain. My gut feeling is this isn't
a good thing to have on your context switch path.

Agreed, probably have to be a compile time option.  That would still give it more exposure than if it required a patch.

We build debug & release versions of everything, with max instrumentation on the former and max optimizations on the latter. I could see this being informative for the debug variant, although that may not be the exact use case that George was after. I see this more as a tool for confirming one's VCPU allocations on a single system with multiple VMs rather than an admin tool for monitoring generic virtualization servers.

-Bruce
 

 -- Keir

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel