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: <20100828015531.GA8341@gvim.org>
Date:	Fri, 27 Aug 2010 18:55:31 -0700
From:	mark gross <markgross@...gnar.org>
To:	Bryan Huntsman <bryanh@...eaurora.org>
Cc:	Kevin Hilman <khilman@...prootsystems.com>,
	Saravana Kannan <skannan@...eaurora.org>,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	James Bottomley <James.Bottomley@...e.de>,
	mark gross <markgross@...gnar.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jonathan Corbet <corbet@....net>,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [PATCH] pm_qos: Add system bus performance parameter

On Fri, Aug 27, 2010 at 11:33:02AM -0700, Bryan Huntsman wrote:
> Kevin Hilman wrote:
> >Saravana Kannan <skannan@...eaurora.org> writes:
> >
> >>Some drivers/devices might need some minimum system bus performance to
> >>provide acceptable service. Provide a PM QoS parameter to send these requests
> >>to.
> >>
> >>The new parameter is named "system bus performance" since it is generic enough
> >>for the unit of the request to be frequency, bandwidth or something else that
> >>might be appropriate. It's up to each implementation of the QoS provider to
> >>define what the unit of the request would be.
> >>
> >>Signed-off-by: Saravana Kannan <skannan@...eaurora.org>
> >
> >With this current design, only one system-wide bus would be managed.
> >What if a platform has more than one independently scalable bus?
> >
> >I think the only scalable way to handle this kind of thing is to have
> >per-device QoS constraints that can then be combined/aggregated by parent
> >devices/busses.
> >
> >At LPC this year, I've proposed per-device QoS constraints[1] as a topic
> >for the PM mini-conf.  I hope some folks from the MSM camp can be there
> >for these discussions.
> >
> >Kevin
> >
> >[1] http://www.linuxplumbersconf.org/2010/ocw/proposals/819
> 
> Yeah, I'm planning on rounding up some MSM folks for LPC this year.
> Power is a big concern for us so it would be good to join the
> discussion.  Initially, I was very keen on the per-device QoS
> contraints but I've since cooled on it.  For our HW, there's not a
> generic unit that can convey enough data for us to act on.  At least
> not w/o lookup tables, etc., at which point the unit loses it's
> value and becomes a generic handle.  I'm looking forward to a good
> group discussion on this topic.  Thanks.
> 
>
I am looking forward to a good discussion too :)

It would be cool if we had a prototype for the per-device qos
constraint idea to use to help guide the discussion.

Power is a big concern for everyone, and everyone doing SOC's have
all have about the same issues to boot with spi, sdio i2c power domains
and clock domains.

If msm is having issues I bet IA and Omap are or soon will have the
exact same class of issues to solve the kernel.

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