lkml.org 
[lkml]   [2010]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
From
Date
Matthew Garrett <mjg@redhat.com> 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


\
 
 \ /
  Last update: 2010-05-14 18:09    [W:0.454 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site