> From: Matthew Locke [mailto:matthew.a.locke at comcast.net] > ... > > Could you say why you think [frequencies and sleep states] > > shouldn't be mixed? Absent argument > > to the contrary, making it a single continuum seems appealing. Why > > have separate policies? > > I know this questions is directed at Pavel but I have similar > concerns. > I agree that making sleep states into operating points is > appealing. > However, if the implementation is just going to special case > the sleep state operating points then they should be handled > separately. As Pavel points out, you can see from Dave's > implementation that the > operating point definition doesn't quite work for both. Voltage and > frequency don't have meaning for the sleep points. The per > point transition callbacks are needed just to handle the > sleep points. > Latency has a very different meaning between the two types. > Also, the type field is required to identify which points > are sleep points and which ones are operating points. I > think the concept of using operating points to define sleep > states could be a valid one but the implementation provided > isn't quite right (yet). --- Well, if the object is to present "the right interface" to a user-space policy manager, then I think the argument about whether the implementations are shared is irrelevant - the whole point would be to abstract away the implementation, which could conceivably be separate hard-coded routines for each operating point. HOWEVER, the second part of your comment, that the interface actually isn't right for describing sleep states, is more compelling and might point a direction for future realignment (or might just be grist for discussion now about the right attributes for operating points. > ... > > I think its more an issue with the implementation rather than > the concept. We can't just have frequency and voltage as > shown in oppoint patches because we don't know which > frequency and voltage they refer to. The number of frequency > and voltage parameters are completely dependent on the > hardware platform. --- I agree that the set of parameters describing an OP should be flexible. --- > > You bring up a more interesting area to look at integrating > sleep states and operating points. Can we add some hooks > that allow us to define which operating point is selected at > resume? Need to think about that a bit:) --- It's an interesting question, and one we (Motorola) don't have hard data to support, yet. Our current implementation remembers the OP in use before sleeping and resumes at the same OP. The argument is that this corresponds to an application that is doing work at a steady-state level (say decoding video), but that has a brief pause to wait for I/O or a timer (say, pausing until the next frame time); then it makes sense that the level of effort required on resume will be the same as before sleeping. Another possible approach would be to automatically resume at the highest OP, on the assumption that whatever wakes you up will be work to do, so you should be prepared to do it and then sink back to a lower OP as the workload diminishes. That argument is especially appropriate if you have a mechanism that aggregates timers or does periodic scheduling, so that you wake up less often, but do more work at each wakeup. We're planning to do some research on this, but it's waiting for the infrequent time when there's a lull in product development work... Scott
