Reworking pm_qos

Posted May 6, 2010 7:47 UTC (Thu) by Gollum (guest, #25237)
Parent article: Reworking pm_qos

It seems like the problem now is that there is no easy way to determine who is making a request for an unreasonable qos, based on the list maintained by the qos subsystem.

i.e. why am I staying awake so much? Oh, *name process is asking for 0 CPU latency.

Now it is:

Why am I staying awake so much? Oh, something (I don't know what) is asking for 0 CPU latency.

Or am I missing something?

Reworking pm_qos

Posted Jun 21, 2010 4:07 UTC (Mon) by mgross (guest, #38112) [Link]

Sorry for having my head in the sand, I totally missed this article last month. You are right. Tracing and runtime debug support is now harder to implement with the new API. However; debug support was never implemented within the old API even though the data was easier to get.

We are working on adding something better these days, (hopefully for 2.6.36 though)