WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] host information in domU over /proc or /sys filesystem

To: Hannes Kuehnemund <hannes.kuehnemund@xxxxxxx>
Subject: Re: [Xen-devel] host information in domU over /proc or /sys filesystem
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 29 May 2007 18:42:09 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 29 May 2007 10:40:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <465C4F19.5000905@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4655B186.8050209@xxxxxxx> <200705282011.45762.mark.williamson@xxxxxxxxxxxx> <465C4F19.5000905@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6
> > The number of physical CPUs the domain's VCPUs are being scheduled across
> > might change dynamically.  You can, however, change the number of VCPUs a
> > domain is allocated as an indication of how many CPUs it should try to
> > optimise for.
>
> That it changes dynamically is not a problem at all. We would collect
> the data, how many physical CPU's are assigned on a 5 minute base in our
> application to keep track of it. We then can check if response times
> correlate with number of physical CPU's.

Hmmmm.

Well, it's perfectly possible for the hosting provider to assign an 
approximate minimum share of the machine to the domU using the credit 
scheduler.  This is specified effectively in terms of "percentage of one 
physical CPU in a period"...

So for a domain with 90% and one vCPU it would try to schedule it 90% of the 
time on whatever PCPU is free.  For a domain with 90% and 2 vCPUs it'll try 
and make sure that the time the two vCPUs get in total is the same amount.  
Domains with > 1 vCPU can use > 100% by this metric.

Anyhow, there are a number of parameters involved here: how much time in total 
the domain should get, how many vCPUs the domain has, and how the time gets 
shared between them.

Rather than trying to sample how many pCPUs the domain gets to run on, perhaps 
it would be better to monitor the total time its vCPUs are being scheduled 
*somewhere*.  Then you can just compare whether your pCPU time allowance 
corresponds to your SLA.

This way the domain still doesn't need to know which specific CPUs it gets 
scheduled on, but you can get all the information you need?

> > dom0 is permitted to access more detailed information about the host
> > machine through a hypercall (use "xm info" to see what's available).
> >
> >> Other important > information would the real memory and the hostname of
> >> the
> >
> > host machine.
> > I'm not sure why a domU would need to know the hostname of the host
> > machine? Also, this could change during migration, so it's not a stable
> > value.
>
> In case nothing like the physical CPU assignment will be implemented,
> domU must know, which CIM server to query to get this kind of
> information. I know that this value will change, and because of this we
> need the information. If the domO would stay the same all the time, I
> could set a parameter in my software to query the CIM server directly,
> which wouldn't work after a migration.
>
> The third possibility is to setup a dedicated VM which interacts between
> all available dom0's and all available domU's. But this is the last
> possible solution I'd prefer, because a third instance to manage is a
> third source of errors.

I'm still not sure why the domU would need to know the host's hostname though?  
Or is it just as a fallback if the CPU data isn't directly available?

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

<Prev in Thread] Current Thread [Next in Thread>