Re: Attempted summary of suspend-blockers LKML thread

[Brian Swetland]

2010/8/5 Rafael J. Wysocki <rjw@xxxxxxx>:
>>
>> Our wakelock stats currently have
>> (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time
>> and last_change. Not all of these are equally important (total_time is
>> most important followed by active_since), but you only have count.
>> Also as discussed before, many wakelocks/suspendblockers are not
>> associated with a struct device.
>
> OK
>
> How much of that is used in practice and what for exactly?
>
> Do you _really_ have to debug the wakelocks in drivers that much?

Debugging power related issues is pretty critical to building
competitive mobile devices.

Throughout the several months of this discussion I have been
continually scratching my head at this "debugability considered
harmful" attitude that I see in reaction to our interest in having the
ability (gated behind a config option even -- really, that'd be fine,
not everyone need enable it) to gather useful stats and examine the
state of the system.

At this point it sounds like there's no interest in the solution we
have, which works and has worked for a few years, and has been revised
10+ times based on feedback here, and no interest in providing a
solution that accomplishes similar functionality, so perhaps it's time
for us to cut our losses and just go back to maintaining our patches
instead of having the same arguments over and over again.

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