Matthew Garrett <mjg@xxxxxxxxxx> writes: > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: > >> The system stays running because there's something to do. The system >> won't suspend until all the processors hit the kernel idle loop and >> the next_timer_interrupt_critical() returns nothing. > > At which point an application in a busy loop cripples you. I think we > could implement your suggestion more easily by just giving untrusted > applications an effectively infinite amount of timer slack, > > but it still doesn't handle the case where an app behaves > excrutiatingly badly. Is design for exruciatingly bad apps a design requirement? If so, opportunistic suspend + suspend blockers fails as well. An app could easily hold a suspend blocker during its entire execution crippling PM. Using opportunistic suspend may possibly allow you contain bad apps/drivers, but at the cost of having to patch already working and trusted apps and known-working kernel code with suspend blockers. IMO, rather than accepting a solution that allows bad apps to run wild, it would be much better to _continue_ focus on tools for finding and containing bad apps. This approach has the added bonus of solving problems on *every* linux-based system, not just Android. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
