Date: Wed, 31 Mar 2010 12:54:19 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Tsuyoshi Ozawa <ozawa+bsd@t-oza.net> Subject: Re: Dynamic ticks in FreeBSD Message-ID: <201003311254.19517.jhb@freebsd.org> In-Reply-To: <411a180c1003300639l13d33451q305a61b2bcd6e3d5@mail.gmail.com> References: <411a180c1003300537g2a1b4879u2d8d952ce9977cb5@mail.gmail.com> <411a180c1003300639l13d33451q305a61b2bcd6e3d5@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003311254.19517.jhb>