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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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