Subject: [GIT PULL] oprofile fixes for v2.6.37

Ingo,

please pull oprofile fixes for v2.6.37 (tip/perf/urgent):

git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git urgent

(uploaded but not yet sync'ed until now)

Thanks,

-Robert


The following changes since commit e1e359273576ee8fe27021356b064c772ed29af3:

ring_buffer: Off-by-one and duplicate events in ring_buffer_read_page (2010-12-23 12:09:30 -0500)

are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git urgent

Andrew Morton (1):
arch/x86/oprofile/op_model_amd.c: perform initialisation on a single CPU

arch/x86/oprofile/op_model_amd.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)


--
Advanced Micro Devices, Inc.
Operating System Research Center


2010-12-29 17:02:39

by Ingo Molnar

[permalink] [raw]
Subject: Re: [GIT PULL] oprofile fixes for v2.6.37


* Robert Richter <[email protected]> wrote:

> Ingo,
>
> please pull oprofile fixes for v2.6.37 (tip/perf/urgent):
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git urgent
>
> (uploaded but not yet sync'ed until now)
>
> Thanks,
>
> -Robert
>
>
> The following changes since commit e1e359273576ee8fe27021356b064c772ed29af3:
>
> ring_buffer: Off-by-one and duplicate events in ring_buffer_read_page (2010-12-23 12:09:30 -0500)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git urgent
>
> Andrew Morton (1):
> arch/x86/oprofile/op_model_amd.c: perform initialisation on a single CPU
>
> arch/x86/oprofile/op_model_amd.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)

Hm, i'm not sure this fix is correct:

static int op_amd_init(struct oprofile_operations *ops)
{
+ /*
+ * init_ibs() preforms implictly cpu-local operations, so pin this
+ * thread to its current CPU
+ */
+ preempt_disable();
init_ibs();
+ preempt_enable();

If init_ibs() is indeed CPU local, then it needs to be called on all CPUs.
Does that happen and if not why not? AFAICS it's only called on one CPU.

Thanks,

Ingo

Subject: Re: [GIT PULL] oprofile fixes for v2.6.37

On 29.12.10 11:37:43, Ingo Molnar wrote:

> Hm, i'm not sure this fix is correct:
>
> static int op_amd_init(struct oprofile_operations *ops)
> {
> + /*
> + * init_ibs() preforms implictly cpu-local operations, so pin this
> + * thread to its current CPU
> + */
> + preempt_disable();
> init_ibs();
> + preempt_enable();
>
> If init_ibs() is indeed CPU local, then it needs to be called on all CPUs.
> Does that happen and if not why not? AFAICS it's only called on one CPU.

It is correct to run init_ibs() only on one cpu. It only checks the
ibs capabilities and sets up pci devices (if necessary). It runs only
on one cpu but operates with the local APIC and some MSRs, thus it is
better to disable preemption.

The cpu setup itself runs in op_amd_setup_ctrs() which is per cpu.

-Robert

--
Advanced Micro Devices, Inc.
Operating System Research Center

2010-12-30 17:38:56

by Ingo Molnar

[permalink] [raw]
Subject: Re: [GIT PULL] oprofile fixes for v2.6.37


* Robert Richter <[email protected]> wrote:

> On 29.12.10 11:37:43, Ingo Molnar wrote:
>
> > Hm, i'm not sure this fix is correct:
> >
> > static int op_amd_init(struct oprofile_operations *ops)
> > {
> > + /*
> > + * init_ibs() preforms implictly cpu-local operations, so pin this
> > + * thread to its current CPU
> > + */
> > + preempt_disable();
> > init_ibs();
> > + preempt_enable();
> >
> > If init_ibs() is indeed CPU local, then it needs to be called on all CPUs. Does
> > that happen and if not why not? AFAICS it's only called on one CPU.
>
> It is correct to run init_ibs() only on one cpu. It only checks the ibs
> capabilities and sets up pci devices (if necessary). It runs only on one cpu but
> operates with the local APIC and some MSRs, thus it is better to disable
> preemption.

Ok, but in that case the prempt_disable()/enable() should be put into init_ibs(),
not be open-coded at the caller like that.

The comment about its cpu-localness could move to init_ibs() as well.

Thanks,

Ingo