* James Kosin <james.kosin.04@cnu.edu> [100506 20:14]:
quoted text
> On 5/6/2010 11:10 PM, Arve Hjønnevåg wrote:
> >>>>         
> >>> One if the benefit we get from using suspend is that an unprivileged
> >>> app that does not have access to suspend blockers cannot prevent
> >>> suspend. You lose this advantage if you trigger suspend only from the
> >>> idle task.

This assumes that you're using cached values for echo mem > /sys/power/state
and the system keeps on running.

IMHO if you want to keep the system running, then you should just use
cpuidle and implement good idle modes.

Then when someting in the userspace knows you've been idle long enough,
you can suspend.

quoted text
> >> If the process (privileged or unprivileged) doesn't want to suspend, why
> >> not just provide an interface to allow suspend to be turned off at the
> >> user level.  This could block the suspend cycle in itself, and you
> >> shouldn't need fine grained off/on cycles.  If an application really
> >> needs the system not to suspend then they (the user) should know the
> >> consequences and power requirements for such a task.
> >>
> >> I didn't say it had to be only from the idle task; but, that is the most
> >> logical place.  If the other threads are not idle then they really
> >> require work and will most likely already have a bock on the suspend anyway.
> >>
> >>     
> > I think you missed my point. Unprivileged processes should not be
> > allowed to prevent suspend.

You could just freeze the GUI process based on some policy if you
worry about misbehaving timers in various apps. This way the cpuidle
modes will allow you to run some userspace policy daemon. And then that
can suspend if needed based on how it's configured.
  
quoted text
> Ah, you want a way for the system to suspend (and enforce the suspend)
> when only unprivileged processes are the only thing running....
> 
> That would mean a lot of work defining the unprivileged (or privileged)
> processes, and properly suspending (or enforcing) when needed.  Yuck. 
> Sorry I commented then, this is really getting deep into what I love to
> do at work.

Hmm, yeah sounds a bit messy.

Tony
--
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/