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

Kevin Hilman
2010-06-03T14:42:37Z

Peter Zijlstra <peterz@infradead.org> writes:

> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
>> > [mtg: ] This has been a pain point for the PM_QOS implementation.
>> They change the constrain back and forth at the transaction level of
>> the i2c driver. The pm_qos code really wasn't made to deal with such
>> hot path use, as each such change triggers a re-computation of what
>> the aggregate qos request is.
>>
>> That should be trivial in the usual case because 99% of the time you can
>> hot path
>>
>> the QoS entry changing is the latest one
>> there have been no other changes
>> If it is valid I can use the cached previous aggregate I cunningly
>> saved in the top QoS entry when I computed the new one
>>
>> (ie most of the time from the kernel side you have a QoS stack)
>
> Why would the kernel change the QoS state of a task? Why not have two
> interacting QoS variables, one for the task, one for the subsystem in
> question, and the action depends on their relative value?

Yes, having a QoS parameter per-subsystem (or even per-device) is very
important for SoCs that have independently controlled powerdomains.
If all devices/subsystems in a particular powerdomain have QoS
parameters that permit, the power state of that powerdomain can be
lowered independently from system-wide power state and power states of
other power domains.

Kevin