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/
Home Products Support Community News


[Xen-ia64-devel] RE: [PATCH] RE: Timer merge

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-ia64-devel] RE: [PATCH] RE: Timer merge
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 8 Sep 2005 09:53:12 +0800
Cc: "Mallick, Asit K" <asit.k.mallick@xxxxxxxxx>
Delivery-date: Thu, 08 Sep 2005 01:50:53 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-topic: [PATCH] RE: Timer merge
>From: Magenheimer, Dan (HP Labs Fort Collins)
>I've given some thought to timer implementation in an SMP
>and am still very unclear as to why it would be necessary
>to use ac_timer for guest timer interrupts... it seems
>like it would be LESS necessary in an SMP.
>Xen itself needs the itm only to peridically invoke
>the scheduler -- and unfortunately without changes to
>core Xen, this requires the ac_timer queue to be used.
>However, this only needs to be done on the Xen boot

Why? That's interesting assertion to me. Scheduler should run on every
physical processor with separate runqueue, both BSP and APs.

>Guests can use the "virtual itm" for anything they want,
>but I think Linux uses the itm only on the boot processor.

Linux uses itm on each physical processor, to trigger scheduler
periodically and individually.

>are disabled).  Yes, maintaining an offset is necessary
>if the guest changes the (virtual) itc and there is
>some itc/itm/offset management required when switching
>in a new domain, but this is very infrequent compared
>to handling guest timer interrupts.

Yes, less frequent but offset is necessary for correctness.

>So... please explain your timer architecture and design
>(prior to submitting the patch).   Why should anything
>be placed into a centrally managed queue?  Especially
>in an SMP.  It just seems slower and more cumbersome
>with the only advantage being that the implementation
>is a bit closer to x86.

Slower but cleaner to enhance. To use ac_timer just provide a uniform
interface to manipulate machine timer source (itm here), to reduce
possible inconsistency and error prone code in several places. I believe
ac_timer also has good algorithm to manage expires on the list, like
handle two close events immediately without actually fire machine
interrupt, etc. In the meantime, we don't want to eliminate necessity of
current fast path, with both can co-exist and tune for later. ;-)


Xen-ia64-devel mailing list

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