Date: Sat, 8 Nov 2008 15:29:56 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: "Alexandre \"Sunny\" Kovalenko" <gaijin.k@gmail.com> Cc: Alexander Motin <mav@freebsd.org>, Sam Leffler <sam@freebsd.org>, freebsd-mobile@freebsd.org Subject: Re: RFC: powerd algorithms enhancements Message-ID: <20081108012859.Y70117@sola.nimnet.asn.au> In-Reply-To: <1226065673.1210.9.camel@RabbitsDen> References: <491208D3.2050901@FreeBSD.org> <20081107033524.A70117@sola.nimnet.asn.au> <1226065673.1210.9.camel@RabbitsDen>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Nov 2008, Alexandre "Sunny" Kovalenko wrote: > On Fri, 2008-11-07 at 16:20 +1100, Ian Smith wrote: > > > > sam's concerns seem tied in with the same kernel > > cpu freq setting stuff, so I gather all that is connected long term .. > > Just to make sure all facts are spelled out: I have had reliable > livelocks with ath + powerd on RELENG_7 with HAL 0.9.x.x. I have not > seen single livelock since pulling HAL 0.10.5.10 in from -CURRENT. So > ath is not that lily-white in that regard either. Perhaps, but I see Sam pointing out that it's a more generic problem. Lots of high interrupt rate gadgets already, plenty more to come. How goes a big burst of gig ethernet on a box that's dropped back to 75MHz? Or fast USB, firewire, whatever .. meanwhile powerd is operating on an entirely different timing level, orders of magnitude less responsive. We're now seeing cpus that can vary freq, with absolute and relative cpufreq drivers enabled, in ratios up to 32:1 or so, so the advice, apart from 'disable powerd' :), seems to be to at least try setting cpufreq.lowest to some reasonable speed for workload, maybe 300MHz? So, at 75MHz it takes maybe 32 times as long to service an interrupt, unless the ISR itself sets freq, does its biz fast, resets freq (or schedules such, maybe) on exit. What sort of interrupt overhead that represents I've no idea, but it smells likely pretty significant, and sounds like a pretty major bit of redesign at kernel level, especially avoiding impacts of such overheads unless strictly necessary. And that from someone who's yet to study the scheduler/s at all .. :) cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081108012859.Y70117>