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] [PATCH] Make HZ a boot-time configurable

To: "Neugebauer, Rolf" <rolf.neugebauer@xxxxxxxxx>, "Kip Macy" <kmacy@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Make HZ a boot-time configurable
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Mon, 9 May 2005 14:20:49 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 09 May 2005 13:20:23 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVUX4wWaafC0HFDT4KrUiud5jCsGAAFEzhQAAarYNA=
Thread-topic: [Xen-devel] [PATCH] Make HZ a boot-time configurable
 
> In addition the scheduler is set up to send the *current* 
> guest a periodic ticker at 100HZ. This last value is 
> hardcoded in xen/common/schedule.c. again this timer is run 
> off the local APIC.
> Arguably, the frequency for this ticker should be settable 
> per guest to reflect its HZ value (or equivalent).

Or done away with altogether...

As I recall, the complication with doing this is that we don't want
periodic timer interrupts to wake the domain up when its otherwise not
running (whether due to having been preempted or being blocked).

At a minimum, we need to make the ticker freq programmable on a
per-domain basis (including '0Hz'). 

Alternatively, we introduce a new event notification function that only
actually 'kicks' the domain if its already runnning.

Which option is preferred? I'd like to see this make the 3.0-testing
cut, though I guess option 1 could be done in a hypervisor-API backward
compatible fashion.
 
Ian

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