From owner-freebsd-acpi@FreeBSD.ORG Wed May 16 07:01:00 2007 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB48816A403 for ; Wed, 16 May 2007 07:01:00 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8FC6313C447 for ; Wed, 16 May 2007 07:01:00 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 12354 invoked from network); 16 May 2007 07:01:02 -0000 Received: from ppp-71-139-42-13.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.42.13) by root.org with ESMTPA; 16 May 2007 07:01:02 -0000 Message-ID: <464AAC1E.7060002@root.org> Date: Wed, 16 May 2007 00:00:46 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.0 (X11/20070424) MIME-Version: 1.0 To: acpi@freebsd.org References: <20070515050404.GK49628@obelix.dsto.defence.gov.au> <1179249135.1149.21.camel@vonnegut> <20070516032813.GB3773@obelix.dsto.defence.gov.au> In-Reply-To: <20070516032813.GB3773@obelix.dsto.defence.gov.au> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: PowerTOP for FreeBSD ? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2007 07:01:00 -0000 Wilkinson, Alex wrote: > 0n Tue, May 15, 2007 at 10:12:14AM -0700, Eric Anholt wrote: > > Heya Eric! > > >Until we get tickless scheduling, it's not of much use. > > I keep hearing about this "tickless scheduling" but know SFA about it. I assume > it means no ticks (HZ) therefore tones less interrupts therefore less power > consumption? Anyone got a link that explains exactly what it is ? Normally timers tick every 1 us on FreeBSD. Most interrupts are serviced with no work to be performed, so it's just wasted computation. The kernel knows when processes are set to wake up. It knows how long a quantum a process deserves when it's first scheduled. From that, a variable tick delay can be calculated. Example: proc 1 is sleeping for 1 second, proc 2 is runnable (100 ms quantum). Timer is set for 100 ms in advance and then proc 2 is started. If timer fires, proc 2 was cpu bound. New computation occurs and next tick scheduled. Example: proc 1 is waiting for IO, proc 2 is sleeping for 1 second. Timer is set for 1 sec in future and the kernel enters the idle halt state (i.e. C1-3). If proc 1's IO completes, ATA irq fires and kernel runs proc 1. If timer irq fires, proc 2 is run. > >However, the power savings on desktop machines from going tickless and > >fixing stupid apps is pretty amazing -- the keithp quote about > >increasing battery life by over 50% was after only about two days of > >fixing stupid apps, and we're looking at trying to do even better for > >certain situations (let the cpu sleep for several frames at a time while > >playing movies, for example). Most of the app fixes that intel people > >playing with this tool have have developed (which has included at least > >ff, evolution, xchat, gaim, network mangler, xf86-video-intel, and > >gnome-terminal) have been pushed upstream already, so we should all be > >seeing the wins soon if we can go tickless. Until then, we'll just get > >the benefit of not blowing out caches and saving some context switches > >from apps waking up in order to do nothing. > > What is meant by "stupid apps" ? Things that poll. -- Nate