>> Hello,
>> in reply to this mail I will send a serie of 4 patches that cleans up
>> expands the alarm timer handling in QEMU. Patches have been rebased
>> CVS.
>> Patch 1 is mostly a cleanup of the existing code; instead of having
>> #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
>old one.
>> Patch 2 implements the "-clock" command line option proposed by
>> and Avi Kivity. By default QEMU tries RTC and then falls back to unix
>> 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
>> 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
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.

>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

Reply via email to