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:	Mon, 6 Sep 2010 22:42:52 -0700
From:	mark gross <markgross@...gnar.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	markgross@...gnar.org, Kevin Hilman <khilman@...prootsystems.com>,
	Saravana Kannan <skannan@...eaurora.org>,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	James Bottomley <James.Bottomley@...e.de>,
	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 Thu, Sep 02, 2010 at 10:09:20PM +0200, Rafael J. Wysocki wrote:
> On Thursday, September 02, 2010, mark gross wrote:
> > On Fri, Aug 27, 2010 at 07:31:46AM -0700, 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
> > 
> > I thought a pm_qos like thing per bus would be a patch or you where
> > going to put up to the driver model. ;)
> > 
> > The current pm_qos would stick around for higher level pm_qos things.
> > So making the system bus and changing to a summation aggregation would
> > be  temporary thing.  
> > 
> > Or are you you saying we shouldn't put system_bus into pm_qos at all and
> > instead we should put effort into adding it to the driver model for
> > buses?
> 
> Hmm, well, what's system_bus?
> 
> Rafael

My understanding is that system_bus is a somewhat generic concept that
has meaning only in platform specific hardware configurations pm_qos
request class for device specific buses.  Memory, SDIO, SPI, i2c etc.

I'm not sure if it should be exposed up to user mode as an ABI.  Its
pretty abstract and its meaning is perhaps a bit mutable across target 
architectures at this time.

--mgross



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