From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 31 16:56:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40E20106566B for ; Wed, 31 Mar 2010 16:56:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 11A978FC1E for ; Wed, 31 Mar 2010 16:56:13 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B2FFB46B2C; Wed, 31 Mar 2010 12:56:12 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id BFCEF8A021; Wed, 31 Mar 2010 12:56:11 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 31 Mar 2010 12:54:19 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <411a180c1003300537g2a1b4879u2d8d952ce9977cb5@mail.gmail.com> <411a180c1003300639l13d33451q305a61b2bcd6e3d5@mail.gmail.com> In-Reply-To: <411a180c1003300639l13d33451q305a61b2bcd6e3d5@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003311254.19517.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 31 Mar 2010 12:56:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Tsuyoshi Ozawa Subject: Re: Dynamic ticks in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 16:56:13 -0000 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