RE: [Xen-devel] ac_timer: time to say goodbye?

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

OK, that answers my question.  I was unaware that wakeup
of inactive domains was queued (and ordered) as ac_timer entries.

Thanks,
Dan 

> -----Original Message-----
> From: Rolf Neugebauer [mailto:rolf.neugebauer@xxxxxxxxx] 
> Sent: Monday, May 23, 2005 5:37 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] ac_timer: time to say goodbye?
> 
> 
> 
> 
> On 23/5/05 10:07 pm, "Magenheimer, Dan (HP Labs Fort Collins)"
> <dan.magenheimer@xxxxxx> wrote:
> 
> >> Of the top of my head:
> >> Each domain has a timer to schedule timeout values. So
> >> depending on how many
> >> domains are blocking the number of timers varies.
> >> Then there is one timer per vcpu to generate a ticker for the
> >> currently
> >> running VM.
> > 
> > Every domain or every *active* domain?
> > 
> > For inactive domains, determining when the next ticker
> > should be delivered could be part of the domain context,
> > with next tick scheduled when it is made active.
> > 
> 
> It's for every "inactive" domain, ie domain which is blocked. 
> Under Linux we
> set a timeout value in the the idle loop to the next timer 
> event the guest
> cares about and then block. This is translated into a 
> ac_timer for that
> domain.
> 
> I don't understand how making this part of the domain context 
> makes this
> simpler. Basically, instead of looking up the head of a 
> generic timer queue
> for the next timeout value, as we do now, you seem to propose 
> that we should
> look up the timeout value for a domain in the list of blocked 
> domain when
> reprogramming the timer (and maybe a couple of other places).
> 
> The order of domains on the schedulers "blocked" list is best 
> left up to the
> scheduler. In the *best* case it is ordered by timeout value 
> so this would
> be functionally equiv to what we have now (except that we 
> might have to
> check for some other variables containing timeout values as 
> well). In the
> worst case we'd have to scan all inactive domains' contexts 
> for the lowest
> timeout value. Actually, we would have to do that anyway if 
> we want to keep
> the ability of having different schedulers. Then, we 
> certainly don't want to
> dictate a way what types of queues a given scheduler *has* to 
> use and which
> order domains should be placed on it. This seems strictly 
> more complicated,
> *and* less generic than what we have now (even if just used 
> for scheduling).
> 
> BTW.: ac_timers are per physical CPU as they are scheduled 
> off the local
> APIC. There is priority queue per local APIC.
> 
> Rolf
> 
> 
> 
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel