Dynamic ticks in FreeBSD

[John Baldwin]

On Tuesday 30 March 2010 9:39:04 am Tsuyoshi Ozawa wrote:
> Hello,
> 
> I started to work dynamic ticks in FreeBSD, and now experimental
> code start to work roughly.
> The code is here : http://github.com/oza/FreeBSD-8.0-dyntick
> 
> The timer interrupt handler works as follows :
> 1. Scan callout queue and get when the timer fire. This is the value
> we can skip.
> 2. Run hardware timer in "oneshot mode" instead of periodic mode.
> My experimental code only work for local apic timer.
> After translating the value which is gotten at 1 to local apic timer
> count, pass the value to local apic timer.
> 3. Exit timer interrupt handler.
> 
> My experimental code needs a kernel module to switch to dynamic
> tick mode. The kernel module is here : http://gist.github.com/345917
> 
> The benchmark is here :
> http://tsuyoshiozawa.blogspot.com/2010/03/started-to-implement-dynticks-
in.html
> 
> The result says that dynticks can save CPU power significantly,
> so this worth to work. But this is incomplete to work kernel components
> correctly. There are a lot of problems:
> 
> 1. The global variable "ticks" isn't incremented by 2 and above.
> This gets worse the response.
> 2. To fix problem 1, I have to hack scheduler and profiler.
> If I do 1, these kernel component doesn't work correctly.
> 
> But 2. is very expensive to implement. I think that it's good to
> switch between periodic ticks mode and dynamic ticks mode
> when isched_idletd is scheduled. So I'm planning to do this as
> a next step.
> 
> If you have some idea or question about this work,
> please let me know.  Thank you!

Are you doing anything to handle the case where the lapic timer is turned off 
when a CPU enters C2 or C3?  The ideal approach in my mind would be to not use 
the lapic timer at all when running in a deadline mode, but give each CPU a 
dedicated HPET comparator.  Alternatively, you could add some special handling 
where CPU 0 never goes into C2 or C3 but sends IPIs to other CPUs in deep idle 
states when necessary (you could also let CPU 0 fake statclock() for said CPUs 
as well perhaps).

-- 
John Baldwin