All of lore.kernel.org
 help / color / mirror / Atom feed
From: MyungJoo Ham <myungjoo.ham@gmail.com>
To: "Turquette, Mike" <mturquette@ti.com>
Cc: Len Brown <len.brown@intel.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-pm@lists.linux-foundation.org
Subject: Re: [PATCH v4 0/3] DEVFREQ, DVFS framework for non-CPU devices
Date: Wed, 17 Aug 2011 19:07:37 +0900	[thread overview]
Message-ID: <CAJ0PZbSJoxNPn=E0y=52+y9uW+y1S7bZXc4vsBUm1QR2RQEPvg@mail.gmail.com> (raw)
In-Reply-To: <CAJOA=zNRidM+y6FokWH9xorinQMWKHTyCGXoTNYCpLOfNPsYNA@mail.gmail.com>

On Thu, Aug 11, 2011 at 10:28 AM, Turquette, Mike <mturquette@ti.com> wrote:
> On Mon, Aug 8, 2011 at 10:27 PM, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:
>> On Tue, Aug 9, 2011 at 4:13 AM, Turquette, Mike <mturquette@ti.com> wrote:
>>> I'm not getting too bogged down with the OPP specifics because I don't
>>> know if that interface is going to be used in the future, and I don't
>>> think that devfreq will need to know about OPPs once the DVFS QoS API
>>> exists.  In that case, devfreq can just requests clock frequencies
>>> through the QoS API.  I view devfreq's usage of the OPP library as
>>> temporary.
>>>
>>> The real issue here is that we don't want some weird feedback loop
>>> with device QoS requests and devfreq targets stepping on each other.
>>>
>>> One way to handle this is to partition QoS use in drivers away from
>>> devfreq usage.  For example, if a GPU supports performance counters
>>> and can introspect its own usage, then it is a perfect candidate for
>>> devfreq; on the flip-side device drivers should *not* be allowed to
>>> put performance/qos constraints on this particular GPU, since we
>>> assume that the performance counters/devfreq governor will handle the
>>> whole job for us.  Since this centralizes the decision-making for the
>>> GPU it is safe for the devfreq->target() call to use the QoS APIs for
>>> controlling the GPU, since no one else will.  This avoids the feedback
>>> loop.
>>>
>>> On the other hand, if the GPU does not support performance counters
>>> then it should not use devfreq at all and rely 100% of QoS constraints
>>> from various sources: the GPU driver might request a high OPP every
>>> time work comes in, coupled with a timeout; if a QoS knob is exported
>>> to userspace then some OpenGL library might hold constraints through
>>> it; or some other kernel driver (video-related?) needs to use the GPU
>>> then it can hold a constraint through the QoS API.
>>>
>>> So there is a clear partition of QoS API usage between devices that
>>> support performance counters and ones that do not.  We want to avoid a
>>> feedback loop here.
>>
>> Such weird feedback loop may happen if the result frequency ranges
>> from QoS are inconsistent with those from DEVFREQ. However, if DEVFREQ
>> provides frequencies that do not violate QoS requirements, there would
>> be no such feedback loop. If they are consistent (DEVFREQ never gives
>> frequencies that do NOT satisfy QoS), DEVFREQ is transparent to PM
>> QoS.
>
> If two devices, x and y both place frequency constraints on device z,
> then QoS should probably aggregate their requests instead of just
> taking the max.  Then if devfreq also determines that it needs to make
> a QoS request against device z, then that will get aggregated on top
> of x and y's requests.  This isn't really what we want since x and y's
> requests may be adequate and devfreq's performance counter sampling is
> just requesting performance for operations which have already placed
> requests.

DEVFREQ won't give contradicting frequencies with PM QoS inputs to the
target device. DEVFREQ will choose one from frequencies that satisfy
the PM QoS inputs from both x and y (probably aggregated by PM QoS
framework) as long as the PM QoS part of the target device driver is
properly implemented by enabling satisfying OPPs and disabling
not-satisfying OPPs.

>
>> For now, with OPPs, DEVFREQ will always select frequencies that
>> satisfy QoS requirements if the driver implementation is correct.
>>
>> However, as you mentioned, if we assume that OPP is going to disappear
>> in the future kernel, then we will somehow need to design an interface
>> for device drivers to provide lists of available frequencies to
>> DEVFREQ and those lists are going to be runtime-update-able and where
>> QoS requirements are applied. As with the current DEVFREQ
>
> I'm not saying that OPP is going to disappear because I have no idea
> what the future holds.
>
> My point is that devfreq doesn't need to know about OPP at all.  The
> code assumes that OPPs exist for the device and take a frequency as
> part of devfreq->profile->get_target_freq (or something like that) and
> they can just pass that frequency to devfreq->profile->target.  If
> that device has support for the OPP library than it can do the job of
> looking up OPPs, etc.

As discussed in the other thread, OPP is the one that describes the
data every DVFS-able device have. Is there any reason to redundantly
define the same data structure and functions that are publicly
available and represent the same things? Every DEVFREQ device will
have multiple pairs of frequencies and voltages associated with the
specific device and use the functions equivalent to those in OPP
library.

>
> Regards,
> Mike
>

Cheers!
MyungJoo
-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858

      reply	other threads:[~2011-08-17 10:07 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-15  8:11 [PATCH v4 0/3] DEVFREQ, DVFS framework for non-CPU devices MyungJoo Ham
2011-07-15  8:11 ` [PATCH v4 1/3] PM: Introduce DEVFREQ: generic DVFS framework with device-specific OPPs MyungJoo Ham
2011-08-02 18:45   ` Kevin Hilman
2011-08-03  8:06     ` MyungJoo Ham
2011-08-02 21:56   ` Kevin Hilman
2011-08-03  6:02     ` MyungJoo Ham
2011-07-15  8:11 ` [PATCH v4 2/3] PM / DEVFREQ: add example governors MyungJoo Ham
2011-07-15  8:11 ` [PATCH v4 3/3] PM / DEVFREQ: add sysfs interface (including user tickling) MyungJoo Ham
2011-06-09 17:11   ` Pavel Machek
2011-07-19  2:14     ` MyungJoo Ham
2011-07-28 22:10 ` [PATCH v4 0/3] DEVFREQ, DVFS framework for non-CPU devices Rafael J. Wysocki
2011-07-29  4:46   ` Turquette, Mike
2011-07-29  9:10     ` Rafael J. Wysocki
2011-07-30  1:02       ` Turquette, Mike
2011-07-30 21:23         ` Rafael J. Wysocki
2011-08-01 21:47           ` Turquette, Mike
2011-08-01  6:22         ` MyungJoo Ham
2011-08-01 22:01           ` Turquette, Mike
2011-08-02  7:17             ` MyungJoo Ham
2011-08-02 22:02   ` Kevin Hilman
2011-08-03  7:03     ` MyungJoo Ham
2011-08-03 17:31       ` Turquette, Mike
2011-08-03 18:33       ` Kevin Hilman
2011-08-04  8:15         ` MyungJoo Ham
2011-08-04 21:59           ` Turquette, Mike
2011-08-05  6:18             ` MyungJoo Ham
2011-08-08 19:13               ` Turquette, Mike
2011-08-09  5:27                 ` MyungJoo Ham
2011-08-11  1:28                   ` Turquette, Mike
2011-08-17 10:07                     ` MyungJoo Ham [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ0PZbSJoxNPn=E0y=52+y9uW+y1S7bZXc4vsBUm1QR2RQEPvg@mail.gmail.com' \
    --to=myungjoo.ham@gmail.com \
    --cc=gregkh@suse.de \
    --cc=kyungmin.park@samsung.com \
    --cc=len.brown@intel.com \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=mturquette@ti.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.