On Fri, Aug 26, 2011 at 11:25:13AM +0900, MyungJoo Ham wrote:
> On Fri, Jul 1, 2011 at 12:11 AM, <jean.pihet@xxxxxxxxxxxxxx> wrote:
> > @@ -129,19 +146,19 @@ static const struct file_operations pm_qos_power_fops = {
> > /* unlocked internal variant */
> > static inline int pm_qos_get_value(struct pm_qos_object *o)
> > {
> > - if (plist_head_empty(&o->requests))
> > + if (plist_head_empty(o->requests))
> > return o->default_value;
> >
> > switch (o->type) {
> > - case PM_QOS_MIN:
> > - return plist_first(&o->requests)->prio;
> > + case PM_QOS_MIN:
> > + return plist_first(o->requests)->prio;
> >
> > - case PM_QOS_MAX:
> > - return plist_last(&o->requests)->prio;
> > + case PM_QOS_MAX:
> > + return plist_last(o->requests)->prio;
> >
> > - default:
> > - /* runtime check for not using enum */
> > - BUG();
> > + default:
> > + /* runtime check for not using enum */
> > + BUG();
> > }
> > }
>
> Hello,
>
>
> Sorry to jump in this late, but, I've got a question in choosing QoS
> value from the list with pm_qos_get_value function and pm_qos_type.
>
> For QoS objects such as network throughput, wouldn't "PM_QOS_ADD" be
> more appropriate than PM_QOS_MAX?
> If A is requesting 10MB/s on NIC-X and B is requesting 5MB/s on NIC-X,
> I guess PM QOS should say NIC-X that it needs to provide 15MB/s, not
> 10MB/s. Or, are we assuming that A and B will never put streams at the
> same time?
This was brought up a few years back as well. The reason we kept the
aggregate QoS for network Throughput as a max instead of a sum was that
there where already a number of interfaces for network shaping and we
didn't have a good answer to the problem of what to do when the
throughput qos requested exceeds hardware capabilities.
Now that I have more experience with handsets I'm not sure it makes any
practical difference to sum or max the throughput qos requests. So if
someone would like it to aggregate throughputs by summation of requests
that could be done.
It turns out its the latency requests that are really used.
The network qos parameters also have a problem with discriminating
between what physical interface the QoS is for. This limitation in the
ABI is partially addressed with some of the work that Jean Pihet's
patches are doing.
--mark
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
