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

[Rolf Neugebauer <rolf.neugebauer@xxxxxxxxx>]

On 23/5/05 9:28 pm, "Magenheimer, Dan (HP Labs Fort Collins)"
<dan.magenheimer@xxxxxx> wrote:

>> What's heavyweight about it? We can maybe slim down the interface a
>> little, but we need a mechanism for managing at least an
>> alarm timeout 
>> per vcpu. I don't imagine anyhting much simpler than ac_timer would
>> really fit the bill.
>> 
>>   -- Keir
>> 
>> Heavy weight? It's a basic heap (priority queue) implementation.
>> Seems to me like a perfectly sensible thing to have in a
>> hypervisor, and
>> its used extensively by all the schedulers.
>> 
>> Thanks,
>> Ian
> 
> I can't say I fully understand the code and usage, so I may
> be missing something, but...
> 
> Is there ever any more than one or two elements in the queue?
> What is the total set of functions called by the queue?

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.

> 
>> its used extensively by all the schedulers.
> 
> Try 'grep -r ac_timer' and see.

As said above every domain has a timer. With grep that probably shows up as
one ;)

> 
> I suspect that the whole functionality of it can be replaced
> with a couple of time variables that are checked and
> manipulated in the timer interrupt code and a single
> scheduler/timer routine in the generic scheduler.
> 
> The queueing mechanism is nice if there are a lot of uses,
> but confusing (and IMHO heavyweight) if not.  I suspect
> the generalized mechanism was good when there was more
> functionality in Xen itself but as more and more migrates
> to domain0, if the remaining usage could be replaced by
> a couple variables, perhaps it should.

What's confusing about the interface? You set a timeout and a function to be
called at that timeout. Then there are  functions to modify and remove a
timer. Pretty straightforward.

It would be more confusing if the timer interrupt code would check a bunch
of variables and then figure out the next timeout value.

Given the use, a priority queue seems the best solution. The implementation
is a bit more complicated as due to the use of the softirq (to avoid the
handler being executed in an interrupt context), the timer slop stuff to
avoid unnecessary races and timer interrupts, and the hack to make this work
if no local apic is available. But all that is hidden behind the interface.

> 
> Not urgent, but if this is the right direction, we shouldn't
> be layering more code on top of it (thus the suggestion of
> deprecating it).

I don't think this will be deprecated, as Keir said we need at least one
implementation of a programmable timer.

rolf

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


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