[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-ia64-devel] RE: [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |