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]

Date:	Tue, 31 Aug 2010 15:38:04 -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 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/