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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
