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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-ia64-devel] RE: [PATCH] RE: Timer merge
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Wed, 7 Sep 2005 08:35:54 -0700
Cc: "Mallick, Asit K" <asit.k.mallick@xxxxxxxxx>
Delivery-date: Wed, 07 Sep 2005 15:34:54 +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
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

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

So, at most one itm on an SMP system will be used for
both Xen and for a guest.  All other itm's will either
be used only for an active guest or not used at all.
On a processor that is not the Xen boot processor,
the timer interrupt is always intended for the active
guest and can be delivered immediately (or queued using
the standard virtual eirr mechanism if virtual interrupts
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.

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.


> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx] 
> Sent: Tuesday, September 06, 2005 3:05 AM
> To: Magenheimer, Dan (HP Labs Fort Collins); Dong, Eddie; 
> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Mallick, Asit K
> Subject: [PATCH] RE: Timer merge
> Hi, Dan,
>       Attached is the first part of timer code merge, also with some
> code clean. There's no fundamental change yet, and now one 
> common timer
> interrupt handler should be able to serve both in the run-time. Later
> we'll send out another patch to cover vitc/vitm and ac_timer stuff
> which, of course will be developed by ifdef first.
>       Tested OK without regression. Please review.
> Signed-off-by Kevin Tian <Kevin.tian@xxxxxxxxx>
> Signed-off-by Eddie Dong <Eddie.dong@xxxxxxxxx> 
> Thanks,
> Kevin

Xen-ia64-devel mailing list

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