All of lore.kernel.org
 help / color / mirror / Atom feed
From: MyungJoo Ham <myungjoo.ham@samsung.com>
To: markgross@thegnar.org
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Dave Jones <mavej@redhat.com>,
	linux-pm@vger.kernel.org,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Kevin Hilman <khilman@ti.com>, Jean Pihet <j-pihet@ti.com>,
	kyungmin.park@samsung.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] PM / QoS: Introduce new classes: DMA-Throughput and DVFS-Latency
Date: Fri, 9 Mar 2012 14:53:43 +0900	[thread overview]
Message-ID: <CAJ0PZbTfw1U8raiwiNX14x+jnaWa7ptAgpaaTJgCCZKZU24TDg@mail.gmail.com> (raw)
In-Reply-To: <20120308034722.GA10286@envy17>

On Thu, Mar 8, 2012 at 12:47 PM, mark gross <markgross@thegnar.org> wrote:
> On Wed, Mar 07, 2012 at 02:02:01PM +0900, MyungJoo Ham wrote:
>> 1. CPU_DMA_THROUGHPUT
...
>> 2. DVFS_LATENCY
>
> The cpu_dma_throughput looks ok to me.  I do however; wonder about the
> dvfs_lat_pm_qos.  Should that knob be exposed to user mode?  Does that
> matter so much?  why can't dvfs_lat use the cpu_dma_lat?
>
> BTW I'll be out of town for the next 10 days and probably will not get
> to this email account until I get home.
>
> --mark
>

1. Should DVFS Latency be exposed to user mode?

It would depend on the policy of the given system; however, yes, there
are systems that require a user interface for DVFS Latency.
With the example of user input response (response to user click,
typing, touching, and etc), a user program (probably platform s/w or
middleware) may input QoS requests. Besides, when a new "application"
is starting, such "middleware" may want faster responses from DVFS
mechanisms.


2. Does DVFS Latency matter?

Yes, in our experimental sets w/ Exynos4210 (those slapped in Galaxy
S2 equivalent; not exactly as I'm not conducted in Android systems,
but Tizen), we could see noticable difference w/ bare eyes for
user-input responses. When we shortened DVFS polling interval with
touches, the touch responses were greatly improved; e.g., losing 10
frames into losing 0 or 1 frame for a sudden input rush.

3. Why not replace DVFS Latency w/ CPU-DMA-Latency/Throughput?

When we implement the user-input response enhancement with CPU-DMA QoS
requests, the PM-QoS will unconditionally increase CPU and BUS
frequencies/voltages with user inputs. However, with many cases it is
unnecessary; i.e., a user input means that there will be unexpected
changes soon; however, the change does not mean that the load will
increase. Thus, allowing DVFS mechanism to evolve faster was enough to
shorten the response time and not to increase frequencies and voltages
when not needed. There were significant difference in power
consumption with this changes if the user inputs were not involving
drastic graphics jobs; e.g., typing a text message.



Cheers!
MyungJoo.

-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics

  reply	other threads:[~2012-03-09  5:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-05  1:46 linux-next: build failure after merge of the cpufreq tree MyungJoo Ham
2012-03-05  1:46 ` MyungJoo Ham
2012-03-07  5:02 ` [PATCH v3] PM / QoS: Introduce new classes: DMA-Throughput and DVFS-Latency MyungJoo Ham
2012-03-07  9:02   ` Rafael J. Wysocki
2012-03-07  9:36     ` MyungJoo Ham
2012-03-09  8:17       ` MyungJoo Ham
2012-03-10 22:22         ` Rafael J. Wysocki
2012-03-08  3:47   ` mark gross
2012-03-09  5:53     ` MyungJoo Ham [this message]
2012-03-10 22:53       ` Rafael J. Wysocki
2012-03-16  8:30         ` MyungJoo Ham
2012-03-17  0:01           ` Rafael J. Wysocki
2012-03-18 17:06           ` mark gross
2012-03-26 12:06             ` MyungJoo Ham
2012-03-26 14:38               ` mark gross
2012-03-18 16:50         ` mark gross
2012-03-10 22:25     ` Rafael J. Wysocki

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=CAJ0PZbTfw1U8raiwiNX14x+jnaWa7ptAgpaaTJgCCZKZU24TDg@mail.gmail.com \
    --to=myungjoo.ham@samsung.com \
    --cc=j-pihet@ti.com \
    --cc=khilman@ti.com \
    --cc=kyungmin.park@samsung.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=markgross@thegnar.org \
    --cc=mavej@redhat.com \
    --cc=myungjoo.ham@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    --cc=sfr@canb.auug.org.au \
    /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.