> > This could potentially make performance-conscious apps "hiccup" > > once every second as this thread goes walking the list looking for > > candidates to shut off. Try to avoid this; if nothing is happening, nothing > > should be running. > > I don't understand this comment at all. Lots of things happen > periodically in the kernel: threads wake up, timers go off... Are you > suggesting that, for example, the page-flush thread shouldn't wake up > from time to time either? While I don't agree that it will be a horrible drain on performance, I do see a large potential for abuse with a big kernel thread. Things like the page-flush thread are well known and (hopefully) optimized entities - the RTPM thread will have to depend on hundreds of driver writers to be kind to not suck time and resources from the system. About the time that somebody puts a large udelay into their AC97 driver to turn off the DAC, then I'm sure we will question our motives in this regard. That said, I think I tend to favor the big kernel thread, or at least timeout threads on a bus level. The single entity handling the idle math timeout would facilitate future issues such as priority in handling idle timeouts (do we address certain buses/devices before others, for example), plus it would help centralize the functionality, and make it easier to control with any future power management policy concepts. Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group <www.amd.com/embeddedprocessors>
