linux-kernel - Performance device PM QoS (was: Re: [PATCH v3 1/2] PM / devfreq: add global PM QoS support)

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] [day] [month] [year] [list]

Message-Id: <201209182327.45024.rjw@sisk.pl>
Date:	Tue, 18 Sep 2012 23:27:44 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	markgross@...gnar.org
Cc:	myungjoo.ham@...sung.com,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"myungjoo.ham@...il.com" <myungjoo.ham@...il.com>,
	박경민 <kyungmin.park@...sung.com>,
	"khilman@...com" <khilman@...com>,
	"jean.pihet@...oldbits.com" <jean.pihet@...oldbits.com>,
	"mturquette@...com" <mturquette@...com>,
	이종화 <jonghwa3.lee@...sung.com>,
	Paul Walmsley <paul@...an.com>
Subject: Performance device PM QoS (was: Re: [PATCH v3 1/2] PM / devfreq: add global PM QoS support)

On Tuesday, September 18, 2012, mark gross wrote:
> On Mon, Sep 17, 2012 at 11:10:09PM +0200, Rafael J. Wysocki wrote:
> > On Monday, September 17, 2012, MyungJoo Ham wrote:

[...]

> > > > What QoS types do you think could be used here?
> > > 
> > > I don't think the devfreq core needs to care of it.
> > > Whatever the device driver wants could be available here.
> > 
> > That's a bit of a problem.  I don't want device drivers to use the global
> > QoS types, because they aren't sufficiently well defined (units are kind of
> > unknown in some cases, for example).
> > 
> > In my opinion it would be better to add performance device PM QoS in analogy
> > with the existing latency device PM QoS.  The unit might be percentage of full
> > performance (0 - 100).
> > 
> > Of course, that only would cover device performance, but there also is the
> > problem of interconnect throughput that may depend on what frequencies are
> > used by devices on it.
> >
> 
> Paul W. and I where talking about a boost interface I think may be worth
> considering.
> 
> We need to take a step back at this point.  What type of algebra is
> needed WRT the device pm_qos analogy?  do we need an ordered set or even
> partial ordering?  Do we need to be able to tell one state is more
> performing than another at all?
> 
> The use cases of these performance levels tend to be platform and device
> specific AFAICT so far.  The units of performance are not portable
> across ISA's and they're interpretation varies from device to device.

However, the approach used in the patchset being discussed in this thread
addresses this problem by mapping different "QoS" values to specific
device operating points with the help of an array.  Of course, the array
has to be provided by either the platform or the driver, but it allows
us to use "portable" QoS values in the core, at least in principle.

> What if we didn't think of it in terms of an ordered field of some sort?
> What if we had a per device boost hash who's meaning is defined by the
> board / device level module but, the interface and use is defined in the
> common code?  If the platform code didn't implement any then those are
> NOOPs if the platform code cares about that device qos then it
> implements and interprets the specific boost qos as needed.
> 
> So in practice when a driver or use case needed qos, it would request a
> qos hash from the platform code to use and that platform code would need
> to interpret that hash in a platform specific way.

That seems to be conceptually similar to what dev_pm_qos_expose_latency_limit()
does.  It essentially allows drivers to request that PM QoS latency constraints
be used for the devices they handle.

> This would remove the portability problem from drivers requested QoS
> levels from assorted devices.  the QoS levels will be a hash, to be
> interpreted by platform code.

I personally think that the QoS levels should be specified in a way allowing
user space to interpret them, so that they can be exposed to the actual user
in a comprehensible manner accross different systems (be it Android or a
random Linux distro).  There may be a mapping between this "portable"
representation and the platform-specific one (or even driver-specific one
if need be), but user space should be able to say what the particular setting
actually means.

> there are a lot of details to work out but I think something could be
> done along these lines.

Possibly, yes.

Thanks,
Rafael
--
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/