Messages in this thread | | | Date | Wed, 01 Sep 2010 20:37:22 -0700 | From | Saravana Kannan <> | Subject | Re: [PATCH] pm_qos: Add system bus performance parameter |
| |
mark gross wrote: > On Tue, Aug 31, 2010 at 03:38:04PM -0700, Saravana Kannan wrote: >> mark gross wrote: >>> On Mon, Aug 30, 2010 at 11:56:54AM -0700, Kevin Hilman >>>>>> 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. >> Kevin, Thanks for explaining exactly what I had in mind. I was >> caught up with other work and was glad to see this discussion moved >> forward. >> >> I pretty much agree with all of Kevin's statements, so here is a >> preemptive "I agree" to all this paragraphs. >> >>> Now I get it! For throughput we need to do a sum. Ok, we need sum >>> comparator/performance aggregaters too! >> Yay! Finally one of my pet peeves with PM QoS is being resolved(?). > > yes, we need to add a summation aggregater to the pm_qos logic and > likely apply it to all the throughput pm_qos parameters. You where > right about that point. (but I'm not budging on the unit less > parameters)
Yeah, I gave up on the unit less parameter.
>>> 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. >> In my opinion, here is where the "best effort" part, if any, comes >> in. PM QoS could do it's best to meet the QoS while keeping power >> low, but if the h/w can't support it, we let it run at highest >> performance and call it "best effort". > > so we don't need to warn if the aggregate qos request exceeds the > capability of the hardware then.
That should work for now. If we see a strong reason for notifying QoS failures we could add it in the future.
>>>> 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. >> I'm not sure having both interfaces would work. Should a single >> client be allowed to keep the *power state* to what's needed for >> 10Mb/s? What happens if another client votes with "I need at least >> 20Mb/s"? > > I need to think some more on this buy its looking like for throughput > we may only want one type of interface because, as you say, it will be > hard to reconcile one against the other. > >> I think the "limit max power-state to X" should be a specific to >> each PM QoS parameter (not its clients) similar to how >> scaling_max_freq works for CPU freq and is not set by each client >> (process - it uses the CPU). > > yes. However; it follows the units of the pm_qos parameter abstraction > more than anything else.
Not sure I understand this line.
>> So, will be be adding a system bus thruput parameter? Is it going to >> have min comparator for now? > > a summation aggregater, with units of KBS.
Ok. Who is going to add the summation "comparator"? I can write a patch for the system bus thruput parameter.
-Saravana
-- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
| |