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

RE: [Xen-devel] [PATCH 1/2] cpu steal time accounting


  • To: "Rik van Riel" <riel@xxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Tue, 21 Feb 2006 22:06:13 +0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 21 Feb 2006 14:19:33 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcY25nokPkXDQ1OnSbqK2sq0wxh6QwABVpAw
  • Thread-topic: [Xen-devel] [PATCH 1/2] cpu steal time accounting

>From: Rik van Riel [mailto:riel@xxxxxxxxxx]
>Sent: 2006年2月21日 20:56
>
>On Tue, 21 Feb 2006, Tian, Kevin wrote:
>
>> Why do you need to add a new VCPUOP while doing same thing as
>> DOM0_GETVCPUINFO?
>
>Because the dom0_ops only work for dom0 and reworking that
>function to allow non-privileged domains to get info just
>on themselves would end up being a way uglier patch.
>

See your point now. Since physical processor id is also exported in your patch, 
will it cause a trend to allow non-privileged domain to query more physical 
context information about domain itself? Like GETDOMAININFO, GETVCPUCONTEXT, 
etc. For example, guest may use gap info between max_pages and tot_pages to 
decide whether eagerly adding free pages as caches. It can also consider that 
info as an indicator of some type of tight resource contention. If it's the 
usage model, maybe we can consider move them out of dom0_ prefix and make it 
common.

Thanks,
Kevin

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


 


Rackspace

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