From owner-freebsd-mobile@FreeBSD.ORG Sat Nov 15 18:01:52 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95B721065694; Sat, 15 Nov 2008 18:01:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F8538FC08; Sat, 15 Nov 2008 18:01:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mAFI1NmU015493; Sat, 15 Nov 2008 13:01:45 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Alexander Motin Date: Sat, 15 Nov 2008 11:32:09 -0500 User-Agent: KMail/1.9.7 References: <200811060901400000@466321507> <200811131606.24804.jhb@freebsd.org> <491D5265.3020003@FreeBSD.org> In-Reply-To: <491D5265.3020003@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811151132.09851.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Sat, 15 Nov 2008 13:01:46 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8636/Sat Nov 15 00:05:47 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Sam Leffler , freebsd-mobile@freebsd.org Subject: Re: RFC: powerd algorithms enhancements X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 18:01:52 -0000 On Friday 14 November 2008 05:26:45 am Alexander Motin wrote: > John Baldwin wrote: > > On Thursday 13 November 2008 03:52:16 pm Alexander Motin wrote: > >> John Baldwin wrote: > >>>> If your system completely freezes at 400MHz, then it spends about 20% of > >>>> CPU time on this at 2GHz. Doesn't it? > >>> Nope. It is usually very idle at full speed. You are free to go buy your > > own > >>> HP nc6220 if you want to see it for yourself. You can also grab the KTR > >>> trace and modified schedgraph.py at www.freebsd.org/~jhb/gpe/. > >> It's very strange to me that you have 100% load at 400MHz, but zero at > >> full speed. It shouldn't be so! > > > > I think systems are more complex than you give them credit for. Imagine what > > CPU frequency changing does to SMI# handlers for example. > > You may be right, I am sure not very good in some hardware aspects, but > neither EST, nor throttling affect system bus operation. I don't see > direct relation there, it could easily be just some > hardware/acpi/whatever bug. Well, some more details are that I occasionally see one of the GPE handlers on my laptop take 750ms (milli-seconds, not micro-seconds) to run at full CPU speed. If I ever close the lid and then raise it, then I will see one of these every few seconds (I added debugging printfs to output the time for "long-running" GPEs to my kernel previously to debug this and they are still there; saw them again this morning). They only take up 0.7% of my CPU when they run at full speed. However, when I drop down from 1867 to, say, 100, then each one now takes several seconds, and with them coming in every few seconds, it ends up live-locking the system, even though at full CPU speed it is < 1% CPU every 5 seconds or so. > >> The fact of system livelocks means that interrupt processing works out > >> of any priorities! Saying that moving all processing into interrupt > >> handlers is a good way, you are saying that having _all_ our system out > >> of any priorities is a good idea. That's actually the situation we are > >> able to see now with heavy network load with polling disabled. System > >> just dies and there is no other way to manage that except enabling polling! > >> > >> Heavy interrupt handlers is _evil_ from the scheduling point of view! It > >> may be faster in some situations, but it makes system unmanageable! > >> There are never will be enough power to fulfill all requirements, so we > >> must take care about the case when there will be more interrupts then we > >> are able to handle. > > > > I'm not advocating moving the entire system into interrupt handlers. Did you > > actually read what I wrote? My point is that if you have something in > > userland that is as important as what gets done in interrupt handlers, the > > solution is to not rip up the entire scheduler to make certain bits of > > userland have a higher priority than interrupts. > > All I wanted to say is that CPU frequency should not be so important for > system operation. Yes, system will be slower and more latent at lower > frequency, but is must be responsible. Scheduler must be able to give > every process (even user-level) it's time quantum. Well, but the problem is that it is that important. The scheduler is responsible for managing the resource known as the "CPU", and we obviously stick the scheduler in the kernel. :) It's not really userland's job to ensure that kernel-level tasks have enough CPU horsepower to execute. -- John Baldwin