[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.