Re: RFC: powerd algorithms enhancements

Ian Smith <[email protected]>
Newsgroups gmane.os.freebsd.devel.mobile
Message-ID <[email protected]>
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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.