On Sun 2006-09-03 17:31:02, Scott E. Preece wrote: > | From: Pavel Machek<pavel at ucw.cz> > | Cc: <amit.kucheria at nokia.com>, <linux-pm at lists.osdl.org> > | User-Agent: Mutt/1.5.11+cvs20060126 > | > | On Sun 2006-09-03 16:21:34, Scott E. Preece wrote: > | > | From: Pavel Machek<pavel at ucw.cz> > | > some reason, in your perception, why definition of operating points > | > really needs to be in the kernel? Definition of the operating points, > | > as opposed to changing from one OP to another, shouldn't have any timing > | > issues, so why isn't a privileged user-space manager a reasonable > | > approach? > | > | For one thing, is not powerop needed for boot? You need to boot in > | some operating point after all :-). > --- > > In the implementation we use, the initial OP is set by the boot > loader. Our kernel power management driver is a module. The assumption > is that booting involves a lot of processing and it makes sense to just > use the highest OP anyway. That makes sense in our environment, but I > wouldn't recommend our version as a general solution, anyway. That's actually regression; cpufreq saves power even while booting. > | > As noted previously, OPs bundle together more than just the > | > frequency. Those of us supporting the OP model believe that you can't > | > intelligently change CPU frequency in isolation and you can't change > | > some of those parameters independently, because only certain > | > combinations work. > | > | That's okay. User gives you combination he wants, and you select "next > | higher" working operating point. > --- > > Hmm. I need to think about that. I guess the OP abstraction *could* be > entirely inside the user-space policy manager, with the kernel exposing > individual interfaces for every parameter that the policy manager would > need to adjust. However, that means that the whole mess has to be at > user level (kernel just implements simple knobs for individual > parameters), because the dependency management between the parameters > would only be known at user level, and means a relatively bulky kernel > interface, since it would expose more things at the interface. That would work for me. But my idea was actually opposite: expose individual knobs to userspace, and then select some operating point (inside kernel) that satisfies given knobs. > On the other hand, that complexity has to be somewhere, so maybe that > would be OK. As I said, I need to think about it... Looking forward for new interface proposal ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
