From: Arnd Bergmann <arnd@arndb.de>
To: linuxppc-dev@ozlabs.org
Cc: Carl Love <carll@us.ibm.com>, Kevin Corry <kevcorry@us.ibm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Questions about porting perfmon2 to powerpc
Date: Thu, 5 Apr 2007 22:08:00 +0200 [thread overview]
Message-ID: <200704052208.01753.arnd@arndb.de> (raw)
In-Reply-To: <200704051455.34600.kevcorry@us.ibm.com>
On Thursday 05 April 2007, Kevin Corry wrote:
> First, the stock 2.6.20 kernel has a prototype in include/linux/smp.h for a
> function called smp_call_function_single(). However, this routine is only
> implemented on i386, x86_64, ia64, and mips. Perfmon2 apparently needs to
> call this to run a function on a specific CPU. Powerpc provides an
> smp_call_function() routine to run a function on all active CPUs, so I used
> that as a basis to add an smp_call_function_single() routine. I've included
> the patch below and was wondering if it looked like a sane approach.
The function itself looks good, but since it's very similar to the existing
smp_call_function(), you should probably try to share some of the code,
e.g. by making a helper function that gets an argument to decide whether
to run on a specific CPU or on all CPUs.
> Next, we ran into a problem related to Perfmon2 initialization and sysfs. The
> problem turned out to be that the powerpc version of topology_init() is
> defined as an __initcall() routine, but Perfmon2's initialization is done as
> a subsys_initcall() routine. Thus, Perfmon2 tries to initialize its sysfs
> information before some of the powerpc cpu information has been initialized.
> However, on all other architectures, topology_init() is defined as a
> subsys_initcall() routine, so this problem was not seen on any other
> platforms. Changing the powerpc version of topology_init() to a
> subsys_initcall() seems to have fixed the bug. However, I'm not sure if that
> is going to cause problems elsewhere in the powerpc code. I've included the
> patch below (after the smp-call-function-single patch). Does anyone know if
> this change is safe, or if there was a specific reason that topology_init()
> was left as an __initcall() on powerpc?
In general, it's better to do initcalls as late as possible, so __initcall()
is preferred over subsys_initcall() if both work. Have you tried doing it
the other way and starting perfmon2 from a regular __initcall()?
Arnd <><
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linuxppc-dev@ozlabs.org
Cc: Kevin Corry <kevcorry@us.ibm.com>,
LKML <linux-kernel@vger.kernel.org>, Carl Love <carll@us.ibm.com>
Subject: Re: Questions about porting perfmon2 to powerpc
Date: Thu, 5 Apr 2007 22:08:00 +0200 [thread overview]
Message-ID: <200704052208.01753.arnd@arndb.de> (raw)
In-Reply-To: <200704051455.34600.kevcorry@us.ibm.com>
On Thursday 05 April 2007, Kevin Corry wrote:
> First, the stock 2.6.20 kernel has a prototype in include/linux/smp.h for a
> function called smp_call_function_single(). However, this routine is only
> implemented on i386, x86_64, ia64, and mips. Perfmon2 apparently needs to
> call this to run a function on a specific CPU. Powerpc provides an
> smp_call_function() routine to run a function on all active CPUs, so I used
> that as a basis to add an smp_call_function_single() routine. I've included
> the patch below and was wondering if it looked like a sane approach.
The function itself looks good, but since it's very similar to the existing
smp_call_function(), you should probably try to share some of the code,
e.g. by making a helper function that gets an argument to decide whether
to run on a specific CPU or on all CPUs.
> Next, we ran into a problem related to Perfmon2 initialization and sysfs. The
> problem turned out to be that the powerpc version of topology_init() is
> defined as an __initcall() routine, but Perfmon2's initialization is done as
> a subsys_initcall() routine. Thus, Perfmon2 tries to initialize its sysfs
> information before some of the powerpc cpu information has been initialized.
> However, on all other architectures, topology_init() is defined as a
> subsys_initcall() routine, so this problem was not seen on any other
> platforms. Changing the powerpc version of topology_init() to a
> subsys_initcall() seems to have fixed the bug. However, I'm not sure if that
> is going to cause problems elsewhere in the powerpc code. I've included the
> patch below (after the smp-call-function-single patch). Does anyone know if
> this change is safe, or if there was a specific reason that topology_init()
> was left as an __initcall() on powerpc?
In general, it's better to do initcalls as late as possible, so __initcall()
is preferred over subsys_initcall() if both work. Have you tried doing it
the other way and starting perfmon2 from a regular __initcall()?
Arnd <><
next prev parent reply other threads:[~2007-04-05 20:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-05 19:55 Questions about porting perfmon2 to powerpc Kevin Corry
2007-04-05 20:08 ` Arnd Bergmann [this message]
2007-04-05 20:08 ` Arnd Bergmann
2007-04-05 20:32 ` Kevin Corry
2007-04-05 20:37 ` Arnd Bergmann
2007-04-05 20:37 ` Arnd Bergmann
2007-04-06 2:35 ` Kevin Corry
2007-04-05 23:04 ` Benjamin Herrenschmidt
2007-04-06 2:44 ` Kevin Corry
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=200704052208.01753.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=carll@us.ibm.com \
--cc=kevcorry@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
/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.