xen-ia64-devel
[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: |
Thu, 8 Sep 2005 05:55:04 -0700 |
Cc: |
"Mallick, Asit K" <asit.k.mallick@xxxxxxxxx> |
Delivery-date: |
Thu, 08 Sep 2005 12:52:33 +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-index: |
AcWnjSOhSjX2nMKXQI2EGFjNgzyS+AAXrvdAAAAqXDAAAf54IAAFcXoAAATDFSAAADCbAAAOO83gAB29uYAAKFIVoAACuHFQAC2vyoAAAx/l4AAEUTKwAhwwsDAAQAHboAAVNqTwABfnDPA= |
Thread-topic: |
[PATCH] RE: Timer merge |
Hmmm... as you say, "please excuse my incautious assertions."
I had a bad night (yesterday).
> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Sent: Wednesday, September 07, 2005 7:53 PM
> To: Magenheimer, Dan (HP Labs Fort Collins); Dong, Eddie;
> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Mallick, Asit K
> Subject: RE: [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
> >processor.
>
> 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.
> >
> >Dan
>
> 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. ;-)
>
> Thanks,
> Kevin
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|