From: Dave Jones <davej@codemonkey.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
cpufreq@lists.linux.org.uk, linuxppc-dev@ozlabs.org,
Jeremy Kerr <jk@ozlabs.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
cbe-oss-dev@ozlabs.org
Subject: Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
Date: Mon, 7 Jul 2008 17:31:05 -0400 [thread overview]
Message-ID: <20080707213105.GD4997@codemonkey.org.uk> (raw)
In-Reply-To: <200807071702.31240.arnd@arndb.de>
On Mon, Jul 07, 2008 at 05:02:30PM +0200, Arnd Bergmann wrote:
> From: Christian Krafft <krafft@de.ibm.com>
>
> This patch adds a cpufreq governor that takes the number of running spus
> into account. It's very similar to the ondemand governor, but not as complex.
> Instead of hacking spu load into the ondemand governor it might be easier to
> have cpufreq accepting multiple governors per cpu in future.
> Don't know if this is the right way, but it would keep the governors simple.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>
> Dave or other cpufreq people, can you take a look at this
> and add an Acked-by when you're happy?
It looks ok on a quick look through. I'm wondering about the multiple governors
thing though. This came up at last years power management summit, but no-one has
mentioned it since. I think it's possible we want to look at things like
this in the future, and not just for cell. I keep hearing mumblings about
future generations of x86's having dedicated coprocessors for certain tasks
that may benefit from the same thing.
> We have one prerequisite patch in the powerpc code (in spufs),
> so should it get merged through powerpc.git?
That's fine with me. Conflicts should be minimal if any at all,
I've got nothing queued up which touches that part of Kconfig/Makefile
One question I do have though, is how userspace scripts are supposed
to know they're to echo cbe_spu_governor into the relevant parts of
sysfs. I've not used anything with a cell. Do they expose the SPUs
as regular CPUs, or do they show up in a different part of the tree?
Dave
--
http://www.codemonkey.org.uk
WARNING: multiple messages have this Message-ID (diff)
From: Dave Jones <davej@codemonkey.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
cpufreq@lists.linux.org.uk, linuxppc-dev@ozlabs.org,
Jeremy Kerr <jk@ozlabs.org>,
cbe-oss-dev@ozlabs.org
Subject: Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
Date: Mon, 7 Jul 2008 17:31:05 -0400 [thread overview]
Message-ID: <20080707213105.GD4997@codemonkey.org.uk> (raw)
In-Reply-To: <200807071702.31240.arnd@arndb.de>
On Mon, Jul 07, 2008 at 05:02:30PM +0200, Arnd Bergmann wrote:
> From: Christian Krafft <krafft@de.ibm.com>
>
> This patch adds a cpufreq governor that takes the number of running spus
> into account. It's very similar to the ondemand governor, but not as complex.
> Instead of hacking spu load into the ondemand governor it might be easier to
> have cpufreq accepting multiple governors per cpu in future.
> Don't know if this is the right way, but it would keep the governors simple.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>
> Dave or other cpufreq people, can you take a look at this
> and add an Acked-by when you're happy?
It looks ok on a quick look through. I'm wondering about the multiple governors
thing though. This came up at last years power management summit, but no-one has
mentioned it since. I think it's possible we want to look at things like
this in the future, and not just for cell. I keep hearing mumblings about
future generations of x86's having dedicated coprocessors for certain tasks
that may benefit from the same thing.
> We have one prerequisite patch in the powerpc code (in spufs),
> so should it get merged through powerpc.git?
That's fine with me. Conflicts should be minimal if any at all,
I've got nothing queued up which touches that part of Kconfig/Makefile
One question I do have though, is how userspace scripts are supposed
to know they're to echo cbe_spu_governor into the relevant parts of
sysfs. I've not used anything with a cell. Do they expose the SPUs
as regular CPUs, or do they show up in a different part of the tree?
Dave
--
http://www.codemonkey.org.uk
next prev parent reply other threads:[~2008-07-07 21:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-07 15:02 powerpc/cell/cpufreq: add spu aware cpufreq governor Arnd Bergmann
2008-07-07 15:02 ` Arnd Bergmann
2008-07-07 17:17 ` [Cbe-oss-dev] " Eric Blossom
2008-07-07 21:02 ` Arnd Bergmann
2008-07-07 21:02 ` Arnd Bergmann
2008-07-07 21:31 ` Dave Jones [this message]
2008-07-07 21:31 ` Dave Jones
2008-07-08 6:43 ` Arnd Bergmann
2008-07-08 6:43 ` Arnd Bergmann
2008-07-08 15:27 ` Dave Jones
2008-07-08 15:27 ` Dave Jones
2008-07-09 3:41 ` Benjamin Herrenschmidt
2008-07-09 3:57 ` Dave Jones
2008-07-10 18:05 ` Dominik Brodowski
2008-07-10 18:05 ` Dominik Brodowski
2008-07-10 21:05 ` Arnd Bergmann
2008-07-10 21:16 ` Dominik Brodowski
2008-07-09 5:18 ` Benjamin Herrenschmidt
2008-07-09 6:29 ` Dave Jones
2008-07-15 13:02 ` Arnd Bergmann
2008-07-15 13:02 ` Arnd Bergmann
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=20080707213105.GD4997@codemonkey.org.uk \
--to=davej@codemonkey.org.uk \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=cbe-oss-dev@ozlabs.org \
--cc=cpufreq@lists.linux.org.uk \
--cc=jk@ozlabs.org \
--cc=linuxppc-dev@ozlabs.org \
--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.