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

[Rolf Neugebauer <rolf.neugebauer@xxxxxxxxx>]

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