From owner-freebsd-mobile@FreeBSD.ORG Wed Nov 12 13:12:01 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 3778C1065740; Wed, 12 Nov 2008 13:12:01 +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 C53548FC1B; Wed, 12 Nov 2008 13:12:00 +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 mACDBNK9084446; Wed, 12 Nov 2008 08:11:54 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-mobile@freebsd.org Date: Tue, 11 Nov 2008 12:06:53 -0500 User-Agent: KMail/1.9.7 References: <200811060901400000@466321507> <491319C0.8090201@freebsd.org> <49132585.4070601@FreeBSD.org> In-Reply-To: <49132585.4070601@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811111206.53809.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 12 Nov 2008 08:11:55 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8620/Wed Nov 12 04:05:38 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,NO_RELAYS autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Alexander Motin , Sam Leffler 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: Wed, 12 Nov 2008 13:12:01 -0000 On Thursday 06 November 2008 12:12:37 pm Alexander Motin wrote: > Sam Leffler wrote: > > Alexander Motin wrote: > >>> The biggest problem I see with powerd is that when a system is > >>> running with a reduced clock frequency interrupts are not processed > >>> at full clock speed. This, for example, breaks the ath driver which > >>> can generate interrupts very quickly when h/w MIB counters overflow > >>> in a noisy environment. Because processing happens at the reduced > >>> frequency until powerd gets to run it causes livelock > >> > >> You wanted to say that ath driver/hardware unable to operate on slow > >> CPUs? Ok, but may be it is an ath driver problem? May be it must use > >> some kind of interrupt moderation to avoid it? > > > > You didn't understand me. I used ath as an example of the general problem. > > I understand you. The real problem I see here is that any hardware > interrupts now can livelock the system. It is not limited to ath. Big > packet rate on any fast enough interface that has any significant > receive processing is able to make system not responding, just because > interrupts will consume all available CPU time. On my laptop the ACPI SCI is the culprit. If I let the CPU drop below 400 mhz, the GPE handler for temperature updates takes so long to run the CPU spends the entire time processing GPEs and never runs userland. Thus, powerd never gets to run. This happens on a "modern" laptop, not a Pentium-100. And actually, at certain speeds it would eventually let userland run enough to bump up. I actually added KTR_SCHED events for ACPI GPE and Task handling and hacked schedgraph to parse them and thus had pretty pictures showing the GPE handler using all CPU time during the multiple-second "hangs" I would get on my laptop with powerd. > powerd just makes that situation more probable as it significantly > reduces CPU performance. Just insert gigabit card into Pentium-100 > system and you will not be able to get there onder the load of only did > not using device polling mode. Rising frequency on interrupt processing > _will_not_ fix the problem, but just hide it for some time, until newer > network cards will be able to handle higher packet rate. It will definitely fix the problem on my laptop. > I think the only solutions for this case can be in allowing scheduler to > really do it's job. Or by moving _everything_ out of interrupt threads > to make them extremely fast and so to avoid the livelock problem, or in > some other way allow scheduler to delay interrupt processing to allow > other (for example user-level) threads to obtain at least some part of > their CPU time slot according to their priorities. > > I don't see how powerd itself could do at least anything with this. The point is that powerd is part of a CPU throttling strategy. If you are going to mess with powerd you need to do so in the context of the overall strategy. -- John Baldwin