linux-kernel - Re: [PATCH] pm_qos: Add system bus performance parameter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C7F1BF2.4050200@codeaurora.org>
Date:	Wed, 01 Sep 2010 20:37:22 -0700
From:	Saravana Kannan <skannan@...eaurora.org>
To:	markgross@...gnar.org
CC:	Kevin Hilman <khilman@...prootsystems.com>,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	James Bottomley <james.bottomley@...e.de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jonathan Corbet <corbet@....net>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/