Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

From: Felipe Contreras
Date: Wed Jun 09 2010 - 04:13:57 EST


On Sat, Jun 5, 2010 at 11:50 PM, Florian Mickler <florian@xxxxxxxxxxx> wrote:
> On Sat, 5 Jun 2010 23:06:03 +0300
> Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote:
>> How would such stats be calculated? I presume at regular intervals you
>> check which applications are holding suspend blockers and increase a
>> counter.
>>
>> How would you do that with the dynamic PM approach? At regular
>> intervals you check for which applications are running (not idle).
>
> IIRC, the patches discussed have debugging infrastructure in
> them. The kernel does the accounting.

We are not talking about debugging, we are talking about stats shown
in user-space so that users can see the offending apps. It doesn't
matter where the accounting is done, it would be at regular intervals
and there's nothing that prevents the dynamic PM approach to offer
similar stats.

>> > The only difference is, that with suspend blockers, he can than
>> > dismiss the applications permission to block suspend and will not miss
>> > his job interview the next day because his phones battery run
>> > out. And also he can use the application to a certain extent.
>>
>> So the difference is between removing the app, and making it run
>> crappy. I don't think that's a strong argument in favor of suspend
>> blockers.
>>
> If you think a little about it, it is. Because if the app wouldn't be
> usable at all, the bug wouldn't get fixed because the user wouldn't use
> it. Or not?

I'm not sure what's your point here. One user not using a certain
application doesn't prevent bugs to get fixed. In fact, less people
using an app will cause less buzz, and less downloads, and less
positive votes... which might wake up the author to think: hey, maybe
I'm doing something wrong? Maybe I should really listen to those bug
reports.

Anyway, my point is that there's nothing special about 3rd party app
stats with suspend blockers.

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