This is a discussion on Re: RFC: powerd algorithms enhancements - FreeBSD ; 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 ...
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 ..
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"