On Thu, 27 May 2010, Matthew Garrett wrote:

quoted text
> On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
> 
> > I can't speak for Thomas, but I'm certainly not arguing that you don't
> > need something that looks more like the blocker side of the logic *in
> > kernel*, because there is stuff that you want to express which isn't tied
> > to the task.
> 
> Sure, if you're not using opportunistic suspend then I don't think 
> there's any real need for the userspace side of this. The question is 
> how to implement something with the useful properties of opportunistic 
> suspend without without implementing something pretty much equivalent to 
> the userspace suspend blockers. I've sent another mail expressing why I 
> don't think your proposed QoS style behaviour provides that.

Opportunistic suspend is just a deep idle state, nothing else. If the
overall QoS requirements allow to enter that deep idle state then the
kernel goes there. Same decision as for all other idle states. You
don't need any user space blocker for this decision, just sensible QoS
information.

Stop thinking about suspend as a special mechanism. It's not - except
for s2disk, which is an entirely different beast.

Thanks,

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