On Mon, Aug 30, 2010 at 11:56:54AM -0700, Kevin Hilman wrote: > mark gross <markgross@xxxxxxxxxxx> writes: > > > On Fri, Aug 27, 2010 at 07:55:37PM -0700, Saravana Kannan wrote: > >> mark gross wrote: > >> >On Fri, Aug 27, 2010 at 01:10:55AM -0700, skannan@xxxxxxxxxxxxxx wrote: > >> >>Ignoring other details for now, the biggest problem with throughput/KBps > >> >>units is that PM QoS can't handle it well in its current state. For KBps > >> >>the requests should be added together before it's "enforced". Just picking > >> >>the maximum won't work optimally. > >> > > >> >well then current pm_qos code for network throughput takes the max. > >> > >> I don't know how the network throughput is enforced, but if the unit > >> is KBps and it's just doing a Max, then I think it's broken. If two > >> clients request 50 KBps and your network can go till 200 KBps, you > >> would still be requesting 50 KBps when you could have requested 100 > >> KBps. > >> > >> Any specific reason PM QoS doesn't support a "summation" "comparitor"? > > > > PM_QoS could do a summation, but keep in mind it pm_qos not qos. pm_qos > > is a best effort thing to constrain power management throttling, not > > provide a true quality of service or deadline scheduling support. > > For me (and I think Saravana too), this is still all about power, but > it's closely tied to QoS. > > For things like busses, which are inherently shared, PM is tightly > coupled with "true" QoS, so I'm not sure I fully follow the distinction > being made between PM QoS and QoS. Seems like the tradeoff is always > between power and performance. > > > If you stick to the full up quality of service mentality you quickly get > > into discussions just like those around memory over commit. Its really > > hard to know when best effort or hard QoS is appropriate. > > > > If you are trying to use pm_qos as a true qos interface then, its > > definitely not up to the task. > > > > example: you have one 100Mb NIC in your box. With PM QoS you could > > have 4 user mode applications requesting 100Mbs PM_Q0S. In this case > > the right thing to do is to constrain the NIC PM to keep it full on and > > the PHY going as fast as it can. But you'll never get 400Mbs out of the > > thing. > > > > So far only max and min really have made sense for pm_qos but, if a case > > pops up where summation makes more sense for aggregating the pm_qos > > requests then I'm open to it. > > Using your example above, what if the 4 apps all request 10Mb/s? > > What is best effort? Leave the NIC in 10Mb/s mode, or bump up the power > state to 100Mb/s mode? Now I get it! For throughput we need to do a sum. Ok, we need sum comparator/performance aggregaters too! Do we also need to figure out the max throughput and warn if the pm_qos requests are going over? I suppose the network stack could register each device with a max bus bandwidth and pm_qos could warn on exceeding the hardware throughput. > This decision is both QoS and PM related. Without summation, the 'max' > request is still 10Mb/s so you would keep the lower power state. But > you also know that none of the clients will get their requested rate. > > There's some gray area here since there is a choice. Was the point > of the request to keep the NIC at the *power-state* needed for 10Mb/s (a > PM request) or was the request saying the app wanted at least 10Mb/s (a > QoS request.) I need to think on this a bit. You are correct, and it looks like we could use both types of interfaces. > > My understanding is that PM QoS is intended to limit power-state > throttling. IOW, in the absence of PM QoS requests, the PM core code is > free to throttle the power of the devices/subsystems/busses etc. If > requests are present, it is no longer free to throttle blindly. > > The question here seems to be whether or not the PM core code should > also be free to increase the power state to meet a combination of PM QoS > requests. To me this is still PM related. Just like in race-to-idle > for the CPU, it might be better for overall power to go to the highter > state for a burst and then be able to fully throttle again. > > Kevin thanks for the example! it really helped me to understand the issue better. --mark -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
