Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756059Ab0HaWiG (ORCPT ); Tue, 31 Aug 2010 18:38:06 -0400 Received: from wolverine01.qualcomm.com ([199.106.114.254]:28013 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755045Ab0HaWiE (ORCPT ); Tue, 31 Aug 2010 18:38:04 -0400 X-IronPort-AV: E=McAfee;i="5400,1158,6091"; a="52930917" Message-ID: <4C7D844C.5050403@codeaurora.org> Date: Tue, 31 Aug 2010 15:38:04 -0700 From: Saravana Kannan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: markgross@thegnar.org CC: Kevin Hilman , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, "Rafael J. Wysocki" , James Bottomley , Frederic Weisbecker , Jonathan Corbet Subject: Re: [PATCH] pm_qos: Add system bus performance parameter References: <1282882403-29824-1-git-send-email-skannan@codeaurora.org> <1282882403-29824-2-git-send-email-skannan@codeaurora.org> <20100827064153.GB3414@gvim.org> <20100828020540.GB8341@gvim.org> <4C787AA9.4090906@codeaurora.org> <20100828225255.GA12402@gvim.org> <878w3o3p55.fsf@deeprootsystems.com> <20100831184030.GB9305@gvim.org> In-Reply-To: <20100831184030.GB9305@gvim.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2941 Lines: 66 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(?). > 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". >> 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 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). So, will be be adding a system bus thruput parameter? Is it going to have min comparator for now? Btw, Mark, I'm a he. Not a she :-) Thanks, Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/