Re: [PATCH v2 RESEND] PM / devfreq: add PM QoS support

[Turquette, Mike]

On Wed, Feb 29, 2012 at 1:43 AM, MyungJoo Ham <myungjoo.ham@xxxxxxxxxxx> wrote:
> +       /* Check the sanity of qos_list/qos_type */
> +       if (profile->qos_type || profile->qos_list) {
> +               switch (profile->qos_type) {
> +               case PM_QOS_CPU_DMA_LATENCY:
> +               case PM_QOS_NETWORK_LATENCY:
> +                       devfreq->qos_use_max = false;
> +                       break;
> +               case PM_QOS_NETWORK_THROUGHPUT:
> +                       devfreq->qos_use_max = true;
> +                       break;

Hello MyungJoo!

I see that you re-using the same old PM QoS handles in this
implementation.  Do you feel this is the right way to do it?  Your
example of using DMA for multimedia devices (given in the changelog)
has nothing to do with network throughput, yet that constraint-type is
used here.

I wonder if a better solution than overloading these classifications exist.

Just to toss around ideas, what about having per-device PM QoS
throughput constraints which are generalized (e.g., not tied to a
concept such as "network").  I've Cc'd Jean Pihet (yet again) who has
some good experience making PM QoS-type interfaces work on a
per-device basis.

I wonder, ultimately, if instead of feeding QoS constraints into
devfreq if a better design might be to have devfreq feed input into a
greater QoS framework.  E.g:

A scalable bus used by many devices might have two different device
drivers that want to call pm_qos_device_tput(...), and also the
devfreq driver for that bus also calls pm_qos_device_tput(...).  So
essentially there are three points in the code where inputs can be
driven into one common per-device QoS layer for the generic concept of
"device throughput".  This way devfreq support is not a prerequisite
for scaling a device in a generic way, but a nice framework for
devices which can monitor their own activity level, built on top of a
per-device pm qos layer.

Thoughts?
Mike
--
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/