Skip site navigation (1)Skip section navigation (2)
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>