Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2

Dor Laor
2007-08-18T16:53:52Z

>> Hello,
>> in reply to this mail I will send a serie of 4 patches that cleans up
>and
>> expands the alarm timer handling in QEMU. Patches have been rebased
on
>QEMU
>> CVS.
>>
>> Patch 1 is mostly a cleanup of the existing code; instead of having
>multiple
>> #ifdefs to handle different timers scattered all over the code I've
>created a
>> modular infrastructure where each timer type is self-contained and
>generic code
>> is more readable. The resulting code is functionally equivalent to
the
>old one.
>>
>> Patch 2 implements the "-clock" command line option proposed by
Daniel
>Berrange
>> and Avi Kivity. By default QEMU tries RTC and then falls back to unix
>timer;
>> user can override the order of the timer through this options. Syntax
>is pretty
>> simple: -clock timer1,timer2,etc. (QEMU will pick the first one that
>works).
>>
>> Patch 3 adds support for HPET under Linux (which is basically my old
>patch). As
>> suggested HPET takes precedence over other timers, but of course this
>can be
>> overridden.
>>
>> Patch 4 introduces "dynticks" timer source; patch is mostly based on
>the work
>> Dan Kenigsberg. dynticks is now the default alarm timer.
>
>Why do you guard dynticks with #ifdef? Is there any reason why you
>wouldn't want to use dynticks?

I think too that it's should be the default.
There is no regression in performance nor behaviour with this option.

We didn't test qemu dyn-tick with kernels that don't have
high-res-timer+dyn-tick.
In this case the dyn-tick minimum res will be 1msec. I believe it should
work ok since this
is the case without any dyn-tick.

So, I join Anthony's vote.

>
>Regards,
>
>Anthony Liguori
>
>> Luca
>
>
>-----------------------------------------------------------------------
-
>-
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems? Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>kvm-devel mailing list
>kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/kvm-devel