On Mon, 1 Aug 2005, Jordan Crouse wrote: > 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. Hmmm... A large delay in a suspend pathway will cause problems no matter how it gets invoked, right? If we have a separate kernel thread for RTPM, then at least the only things affected will be other RTPM activities. Whereas if we use keventd instead to provide a process context, lots of other things would be affected as well. > 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. Those are good ideas. Alan Stern
