Re: [RFD] Automatic suspend

[Rafael J. Wysocki]

On Monday 16 February 2009, Woodruff, Richard wrote:
> 
> > From: Arjan van de Ven [mailto:arjan@xxxxxxxxxxxxx]
> > Sent: Monday, February 16, 2009 3:52 PM
> > On Mon, 16 Feb 2009 15:32:06 -0600
> > "Woodruff, Richard" <r-woodruff2@xxxxxx> wrote:
> > >
> > > - It provides a way to handle overdrive/turbo operating points out of
> > > band from the generically tuned cpufreq governors like ondemand.  The
> > > way we characterize overdrive is stricter then what Intel has talked
> > > about for x86.
> >
> > if you have an improved-for-your-systems governor then I'm sure that is
> > very welcome in the kernel.
> 
> No, the generic governors were not substantially improved. Not every customer is using cpufreq for DVFS. As such we went underneath it. If we had more community presence at the start time we might have also tried that.
> 
> > I think just about all of us agree that the final decision needs to be
> > in the driver (possibly followed by something that gets various device
> > requests and combines it into hw settings); we're just talking about
> > what inputs feed into that decision ;)
> >
> > And for different types of devices that's guaranteed to be different...
> > and sometimes we'll be hampered by existing interfaces, so we might end
> > up with hacky stuff.
> 
> Is there some kind of roadmap which can be plotted which goes from course to more granular control?
> 
> Phase 1 (all or nothing): like wakelocks (minus back light):
> system-auto-suspend-on, system-auto-suspend-off.  The drivers can still veto
> as they do today.
> 
> Phase 2: Subsystem generic tunable, on say latency + bandwidth. Start with
> CPU then move to classes like USB.
> 
> Phase 3: ??? if needed add direct device control, hints on an extended
> fadvise(), and explicit control left to open/close and direct ioctls?
> 
> I don't know that 1,2,3 above even make sense.

I'd like to talk about this. 

Phase 1: I agree that system-auto-suspend-on, system-auto-suspend-off would be
useful, but I don't like the wakelocks interface.  Do you think there is an
alternative way/mechanism of doing this?

Phase 2: I'm not sure.  We may want to introduce such things for various
subsystems in parallel (eg. USB already has such things).

Phase 3: Probably explicit control left to open/close.

> However, the notion of actually plotting out a course with goals does as it
> will take a long time and it is good to get some benefit along the way.

Agreed.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/