From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <len.brown@intel.com>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [Ksummit-discuss] [TECH(CORE?) TOPIC] Energy conservation bias interfaces
Date: Wed, 14 May 2014 22:21:22 +0200 [thread overview]
Message-ID: <CAKMK7uFfUrhEe1e9rYh7jdw8smPgKka0hUGKoMisgY4oF=nRvg@mail.gmail.com> (raw)
In-Reply-To: <1963221.UGZYU13xOX@vostro.rjw.lan>
On Wed, May 14, 2014 at 1:55 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> In addition to that, the CPU scheduler is not the only subsystem where
> things may not be either on or off. Take the graphics for example (at
> least in the case of more complicated adapters). There certainly are
> energy efficiency vs performance tradeoffs there.
There's actually really hilarious interaction issues going on. Up
until recently we've had bugs with the gpu turbo where you had to keep
the cpu unecessarily busy to get the highest gpu frequencies. Which
meant that optimizations in the userspace driver to be more cpu
efficient actually reduced performance. Essentially the gpu wasn't
ramping up because the cpu was slow in delivering new work and the cpu
wasn't ramping up becasue the gpu was slow in processing it and so
resulted in stalls. Keeping one of them artificially busy helped ;-)
Now we do ramp the gpu freq manually in the driver and help out the
cpu side by using io_schedule waits instead of normal ones.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-05-14 20:21 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 12:54 Rafael J. Wysocki
2014-05-06 13:37 ` Dave Jones
2014-05-06 13:49 ` Peter Zijlstra
2014-05-06 14:51 ` Morten Rasmussen
2014-05-06 15:39 ` Peter Zijlstra
2014-05-06 16:04 ` Morten Rasmussen
2014-05-08 12:29 ` Rafael J. Wysocki
2014-05-06 14:34 ` Morten Rasmussen
2014-05-06 17:51 ` Preeti U Murthy
2014-05-08 12:58 ` Rafael J. Wysocki
2014-05-08 14:57 ` Iyer, Sundar
2014-05-12 16:44 ` Preeti U Murthy
2014-05-13 23:36 ` Rafael J. Wysocki
2014-05-15 10:37 ` Preeti U Murthy
2014-05-10 16:59 ` Preeti U Murthy
2014-05-07 21:03 ` Paul Gortmaker
2014-05-12 11:53 ` Amit Kucheria
2014-05-12 12:31 ` Morten Rasmussen
2014-05-13 5:52 ` Amit Kucheria
2014-05-13 9:59 ` Morten Rasmussen
2014-05-13 23:55 ` Rafael J. Wysocki
2014-05-14 20:21 ` Daniel Vetter [this message]
2014-05-12 20:58 ` Mark Brown
2014-05-07 5:20 Iyer, Sundar
2014-05-08 8:59 ` Preeti U Murthy
2014-05-08 14:23 ` Iyer, Sundar
2014-05-12 10:31 ` Morten Rasmussen
2014-05-12 10:55 ` Iyer, Sundar
2014-05-13 23:48 ` Rafael J. Wysocki
2014-05-12 16:06 ` Preeti U Murthy
2014-05-13 23:29 ` Rafael J. Wysocki
2014-05-12 11:14 ` Morten Rasmussen
2014-05-12 17:13 ` Preeti U Murthy
2014-05-12 17:30 ` Iyer, Sundar
2014-05-13 6:28 ` Amit Kucheria
2014-05-13 23:41 ` Rafael J. Wysocki
2014-05-14 9:15 ` Daniel Lezcano
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='CAKMK7uFfUrhEe1e9rYh7jdw8smPgKka0hUGKoMisgY4oF=nRvg@mail.gmail.com' \
--to=daniel.vetter@ffwll.ch \
--cc=daniel.lezcano@linaro.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=len.brown@intel.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox