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: <20100901142804.GA13985@gvim.org>
Date:	Wed, 1 Sep 2010 07:28:04 -0700
From:	mark gross <markgross@...gnar.org>
To:	Saravana Kannan <skannan@...eaurora.org>
Cc:	markgross@...gnar.org, 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

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)

> >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.

> >>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.

> 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.

> Btw, Mark, I'm a he. Not a she :-)

I made an effort to not use he/she in all my email's with you because I
couldn't tell from your name.  I must have screwed up in one of my
emails.

--mark

--
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/