> The problem is determining how to constrain it to go idle, where "idle" > is defined as "Doesn't wake up until a wakeup event is received". It's > acceptable for something to use as much CPU as it wants when the user is > actively interacting with the device, but in most cases processes > shouldn't be permitted to use any CPU when the session is idle. The > question is how to implement something that allows a CPU-guzzling > application to be idled without impairing its ability to process wakeup > events.
>From your literal description: setpriority. signal, process groups. kill(-desktopgroup, SIGSTOP); kill(-desktopgroup, SIGCONT); kill(pid_i_am_crit_eventing, SIGCONT); or SIGTSTP might be friendlier as a well behaved smart app can catch it, fire it into the event loop and elegantly save and sleep. Some window managers played with doing setpriority for focussed windows. OLPC the same thing for OOM targets via /proc/oom_adj The scheduler can happily do this, the power management will also recognize STOPPED processes as no impediment to suspend. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html