linux-kernel - Re: [PATCH v2 RESEND] PM / devfreq: add 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]

Date:	Mon, 5 Mar 2012 10:09:23 +0900
From:	MyungJoo Ham <myungjoo.ham@...il.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	"Turquette, Mike" <mturquette@...com>,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Kevin Hilman <khilman@...com>,
	mark gross <markgross@...gnar.org>,
	Jean Pihet <jean.pihet@...oldbits.com>
Subject: Re: [PATCH v2 RESEND] PM / devfreq: add PM QoS support

On Mon, Mar 5, 2012 at 7:30 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Wednesday, February 29, 2012, Turquette, Mike wrote:
>> On Wed, Feb 29, 2012 at 1:43 AM, MyungJoo Ham <myungjoo.ham@...sung.com> wrote:
>> > +       /* Check the sanity of qos_list/qos_type */
>> > +       if (profile->qos_type || profile->qos_list) {
>> > +               switch (profile->qos_type) {
>> > +               case PM_QOS_CPU_DMA_LATENCY:
>> > +               case PM_QOS_NETWORK_LATENCY:
>> > +                       devfreq->qos_use_max = false;
>> > +                       break;
>> > +               case PM_QOS_NETWORK_THROUGHPUT:
>> > +                       devfreq->qos_use_max = true;
>> > +                       break;
>>
>> Hello MyungJoo!
>>
>> I see that you re-using the same old PM QoS handles in this
>> implementation.  Do you feel this is the right way to do it?  Your
>> example of using DMA for multimedia devices (given in the changelog)
>> has nothing to do with network throughput, yet that constraint-type is
>> used here.
>>
>> I wonder if a better solution than overloading these classifications exist.
>>
>> Just to toss around ideas, what about having per-device PM QoS
>> throughput constraints which are generalized (e.g., not tied to a
>> concept such as "network").  I've Cc'd Jean Pihet (yet again) who has
>> some good experience making PM QoS-type interfaces work on a
>> per-device basis.
>>
>> I wonder, ultimately, if instead of feeding QoS constraints into
>> devfreq if a better design might be to have devfreq feed input into a
>> greater QoS framework.  E.g:
>>
>> A scalable bus used by many devices might have two different device
>> drivers that want to call pm_qos_device_tput(...), and also the
>> devfreq driver for that bus also calls pm_qos_device_tput(...).  So
>> essentially there are three points in the code where inputs can be
>> driven into one common per-device QoS layer for the generic concept of
>> "device throughput".  This way devfreq support is not a prerequisite
>> for scaling a device in a generic way, but a nice framework for
>> devices which can monitor their own activity level, built on top of a
>> per-device pm qos layer.
>>
>> Thoughts?
>
> I agree with the general idea, definitely would prefer it to what is
> currently being proposed.

Supporting per-device PM-QoS at devfreq is an option that I'm
considering as well as this global PM-QoS. I simply thought to
implement that after global Pm-QoS. (I'm intendeing to support both at
devfreq)

First of all, this is not going to be tied to DMA-BUS only as
currently we are implementing this on other types of devices as well
including GPU, Memory-interface, and others (IPs related with graphics
and/or multimedia); other manufactorers told that they are
implementing these. Although devfreq is now related with DMA_LATENCY
only, those NETWORK_* are added for the generality. And DMA_THROUGHPUT
and DVFS_LATENCY will be added as well if they are added to global
PM_QOS classes.

However, with BUS(w/ DMA) devfreq, the problem with using per-device
PM-QoS only at devfreq is that the devices that requests QoS on the
bus may be attached to different types of bus. The QoS value for bus
in Exynos4210 will be different from Exynos4412 or Exynos5410 while an
identical IP (or in-SoC device) can be attached to all the three chips
(which we are experiencing). When that IP requests QoS value to the
bus, we need a standardized value, not a value specific to an SoC. We
may ensure that the all Exynos bus drivers to use the same metrics if
the IP is only attached to SoCs of a single company. However, there
are IPs that are attached to multiple companies' SoCs; such as most
GPUs. (And GPUs often request QoS values to busses.)

Cheers!
MyungJoo.

-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
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/