All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt@console-pimps.org>
To: Robert Richter <robert.richter@amd.com>
Cc: linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
	Paul Mundt <lethal@linux-sh.org>,
	Russell King <linux@arm.linux.org.uk>,
	linux-arm-kernel@lists.infradead.org, linux-sh@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	linux-arch@vger.kernel.org
Subject: Re: [PATCH V2 4/4] sh: Use the perf-events backend for oprofile
Date: Fri, 27 Aug 2010 21:19:46 +0100	[thread overview]
Message-ID: <20100827201946.GB18829@console-pimps.org> (raw)
In-Reply-To: <20100827145901.GO22783@erda.amd.com>

On Fri, Aug 27, 2010 at 04:59:01PM +0200, Robert Richter wrote:
> On 26.08.10 15:09:19, Matt Fleming wrote:
> > Use the perf-events based wrapper for oprofile available in
> > drivers/oprofile. This allows us to centralise the code to control
> > performance counters.
> > 
> > Signed-off-by: Matt Fleming <matt@console-pimps.org>
> > ---
> > 
> > Paul,
> > 
> > I dropped the CONFIG_PERF_EVENTS dependency from the Makefile in this
> > version because to do anything useful we need perf events anyway.
> 
> Initialization should simply fail with a printk message for this case,
> implement function stubs for the !CONFIG_PERF_EVENTS case instead in
> the oprofile.h header file.

I didn't do this because I was hoping that eventually we'd make
CONFIG_OPROFILE select PERF_EVENTS. Would you be OK making that change
instead? Runtime failure is best avoided where possible, especially when
we can sort this out at compile time.

> > 
> >  arch/sh/oprofile/Makefile  |    2 +-
> >  arch/sh/oprofile/common.c  |   96 ++++++++-----------------------------------
> >  arch/sh/oprofile/op_impl.h |   33 ---------------
> >  3 files changed, 19 insertions(+), 112 deletions(-)
> >  delete mode 100644 arch/sh/oprofile/op_impl.h
> > 
> > diff --git a/arch/sh/oprofile/Makefile b/arch/sh/oprofile/Makefile
> > index 4886c5c..e1015ae 100644
> > --- a/arch/sh/oprofile/Makefile
> > +++ b/arch/sh/oprofile/Makefile
> > @@ -4,6 +4,6 @@ DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
> >  		oprof.o cpu_buffer.o buffer_sync.o \
> >  		event_buffer.o oprofile_files.o \
> >  		oprofilefs.o oprofile_stats.o \
> > -		timer_int.o )
> > +		timer_int.o oprofile_perf.o )
> >  
> >  oprofile-y	:= $(DRIVER_OBJS) common.o backtrace.o
> > diff --git a/arch/sh/oprofile/common.c b/arch/sh/oprofile/common.c
> > index ac60493..f8d4a84 100644
> > --- a/arch/sh/oprofile/common.c
> > +++ b/arch/sh/oprofile/common.c
> > @@ -17,71 +17,23 @@
> >  #include <linux/init.h>
> >  #include <linux/errno.h>
> >  #include <linux/smp.h>
> > +#include <linux/perf_event.h>
> 
> I don't see a reason why this must be included here.
> 
> It's only for sh_pmu_name() and sh_pmu_num_events(), so the interface
> looks wrong here. It should be in oprofile_perf.c. The functions
> should be generic non-arch perf code. See below.

These functions are inherently architecture-specific. See my reply to
your response to patch 2/4.

> >  #include <asm/processor.h>
> > -#include "op_impl.h"
> > -
> > -static struct op_sh_model *model;
> > -
> > -static struct op_counter_config ctr[20];
> >  
> >  extern void sh_backtrace(struct pt_regs * const regs, unsigned int depth);
> >  
> > -static int op_sh_setup(void)
> > -{
> > -	/* Pre-compute the values to stuff in the hardware registers.  */
> > -	model->reg_setup(ctr);
> > -
> > -	/* Configure the registers on all cpus.  */
> > -	on_each_cpu(model->cpu_setup, NULL, 1);
> > -
> > -        return 0;
> > -}
> > -
> > -static int op_sh_create_files(struct super_block *sb, struct dentry *root)
> > -{
> > -	int i, ret = 0;
> > -
> > -	for (i = 0; i < model->num_counters; i++) {
> > -		struct dentry *dir;
> > -		char buf[4];
> > -
> > -		snprintf(buf, sizeof(buf), "%d", i);
> > -		dir = oprofilefs_mkdir(sb, root, buf);
> > -
> > -		ret |= oprofilefs_create_ulong(sb, dir, "enabled", &ctr[i].enabled);
> > -		ret |= oprofilefs_create_ulong(sb, dir, "event", &ctr[i].event);
> > -		ret |= oprofilefs_create_ulong(sb, dir, "kernel", &ctr[i].kernel);
> > -		ret |= oprofilefs_create_ulong(sb, dir, "user", &ctr[i].user);
> > -
> > -		if (model->create_files)
> > -			ret |= model->create_files(sb, dir);
> > -		else
> > -			ret |= oprofilefs_create_ulong(sb, dir, "count", &ctr[i].count);
> > -
> > -		/* Dummy entries */
> > -		ret |= oprofilefs_create_ulong(sb, dir, "unit_mask", &ctr[i].unit_mask);
> > -	}
> > -
> > -	return ret;
> > -}
> > -
> > -static int op_sh_start(void)
> > +static char *op_name_from_perf_name(const char *name)
> >  {
> > -	/* Enable performance monitoring for all counters.  */
> > -	on_each_cpu(model->cpu_start, NULL, 1);
> > +	if (!strcmp(name, "SH-4A"))
> > +		return "sh/sh4a";
> > +	if (!strcmp(name, "SH7750"))
> > +		return "sh/sh7750";
> 
> With that implementation we always have to touch the code for new
> cpus. Maybe we derive it from the perf name, e.g. making all lowercase
> and removing dashes?

Is this code really that bad that we need to start playing string
manipulation games?

> >  
> > -	return 0;
> > -}
> > -
> > -static void op_sh_stop(void)
> > -{
> > -	/* Disable performance monitoring for all counters.  */
> > -	on_each_cpu(model->cpu_stop, NULL, 1);
> > +	return NULL;
> >  }
> >  
> >  int __init oprofile_arch_init(struct oprofile_operations *ops)
> >  {
> > -	struct op_sh_model *lmodel = NULL;
> >  	int ret;
> >  
> >  	/*
> > @@ -91,40 +43,28 @@ int __init oprofile_arch_init(struct oprofile_operations *ops)
> >  	 */
> >  	ops->backtrace = sh_backtrace;
> >  
> > -	/*
> > -	 * XXX
> > -	 *
> > -	 * All of the SH7750/SH-4A counters have been converted to perf,
> > -	 * this infrastructure hook is left for other users until they've
> > -	 * had a chance to convert over, at which point all of this
> > -	 * will be deleted.
> > -	 */
> > -
> > -	if (!lmodel)
> > -		return -ENODEV;
> >  	if (!(current_cpu_data.flags & CPU_HAS_PERF_COUNTER))
> >  		return -ENODEV;
> >  
> > -	ret = lmodel->init();
> > -	if (unlikely(ret != 0))
> > -		return ret;
> > +	ops->setup		= oprofile_perf_setup;
> > +	ops->create_files	= oprofile_perf_create_files;
> > +	ops->start		= oprofile_perf_start;
> > +	ops->stop		= oprofile_perf_stop;
> > +	ops->cpu_type		= op_name_from_perf_name(sh_pmu_name());
> >  
> > -	model = lmodel;
> > +	oprofile_perf_set_num_counters(sh_pmu_num_events());
> >  
> > -	ops->setup		= op_sh_setup;
> > -	ops->create_files	= op_sh_create_files;
> > -	ops->start		= op_sh_start;
> > -	ops->stop		= op_sh_stop;
> > -	ops->cpu_type		= lmodel->cpu_type;
> > +	ret = oprofile_perf_init();
> 
> Instead of exporting all the functions above implement something like:
> 
> 	name = op_name_from_perf_name(sh_pmu_name());
> 	num_events = sh_pmu_num_events();
> 	ret = oprofile_perf_init(ops, name, num_events);
> 
> We will then have only oprofile_perf_init() and oprofile_perf_exit()
> as interface which is much cleaner.

Well, the reason that I left it this way is so that architectures can
choose to implement wrappers around the oprofile_perf_* functions. I
don't think ARM or SH actually need wrappers (the only extra thing that
ARM does is locking which SH should probably do too) but I assumed there
was a reason that these functions pointers were exposed originally. I
haven't look at what other architectures would do. I'll take a look at
that.

WARNING: multiple messages have this Message-ID (diff)
From: Matt Fleming <matt@console-pimps.org>
To: Robert Richter <robert.richter@amd.com>
Cc: linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
	Paul Mundt <lethal@linux-sh.org>,
	Russell King <linux@arm.linux.org.uk>,
	linux-arm-kernel@lists.infradead.org, linux-sh@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	linux-arch@vger.kernel.org
Subject: Re: [PATCH V2 4/4] sh: Use the perf-events backend for oprofile
Date: Fri, 27 Aug 2010 20:19:46 +0000	[thread overview]
Message-ID: <20100827201946.GB18829@console-pimps.org> (raw)
In-Reply-To: <20100827145901.GO22783@erda.amd.com>

On Fri, Aug 27, 2010 at 04:59:01PM +0200, Robert Richter wrote:
> On 26.08.10 15:09:19, Matt Fleming wrote:
> > Use the perf-events based wrapper for oprofile available in
> > drivers/oprofile. This allows us to centralise the code to control
> > performance counters.
> > 
> > Signed-off-by: Matt Fleming <matt@console-pimps.org>
> > ---
> > 
> > Paul,
> > 
> > I dropped the CONFIG_PERF_EVENTS dependency from the Makefile in this
> > version because to do anything useful we need perf events anyway.
> 
> Initialization should simply fail with a printk message for this case,
> implement function stubs for the !CONFIG_PERF_EVENTS case instead in
> the oprofile.h header file.

I didn't do this because I was hoping that eventually we'd make
CONFIG_OPROFILE select PERF_EVENTS. Would you be OK making that change
instead? Runtime failure is best avoided where possible, especially when
we can sort this out at compile time.

> > 
> >  arch/sh/oprofile/Makefile  |    2 +-
> >  arch/sh/oprofile/common.c  |   96 ++++++++-----------------------------------
> >  arch/sh/oprofile/op_impl.h |   33 ---------------
> >  3 files changed, 19 insertions(+), 112 deletions(-)
> >  delete mode 100644 arch/sh/oprofile/op_impl.h
> > 
> > diff --git a/arch/sh/oprofile/Makefile b/arch/sh/oprofile/Makefile
> > index 4886c5c..e1015ae 100644
> > --- a/arch/sh/oprofile/Makefile
> > +++ b/arch/sh/oprofile/Makefile
> > @@ -4,6 +4,6 @@ DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
> >  		oprof.o cpu_buffer.o buffer_sync.o \
> >  		event_buffer.o oprofile_files.o \
> >  		oprofilefs.o oprofile_stats.o \
> > -		timer_int.o )
> > +		timer_int.o oprofile_perf.o )
> >  
> >  oprofile-y	:= $(DRIVER_OBJS) common.o backtrace.o
> > diff --git a/arch/sh/oprofile/common.c b/arch/sh/oprofile/common.c
> > index ac60493..f8d4a84 100644
> > --- a/arch/sh/oprofile/common.c
> > +++ b/arch/sh/oprofile/common.c
> > @@ -17,71 +17,23 @@
> >  #include <linux/init.h>
> >  #include <linux/errno.h>
> >  #include <linux/smp.h>
> > +#include <linux/perf_event.h>
> 
> I don't see a reason why this must be included here.
> 
> It's only for sh_pmu_name() and sh_pmu_num_events(), so the interface
> looks wrong here. It should be in oprofile_perf.c. The functions
> should be generic non-arch perf code. See below.

These functions are inherently architecture-specific. See my reply to
your response to patch 2/4.

> >  #include <asm/processor.h>
> > -#include "op_impl.h"
> > -
> > -static struct op_sh_model *model;
> > -
> > -static struct op_counter_config ctr[20];
> >  
> >  extern void sh_backtrace(struct pt_regs * const regs, unsigned int depth);
> >  
> > -static int op_sh_setup(void)
> > -{
> > -	/* Pre-compute the values to stuff in the hardware registers.  */
> > -	model->reg_setup(ctr);
> > -
> > -	/* Configure the registers on all cpus.  */
> > -	on_each_cpu(model->cpu_setup, NULL, 1);
> > -
> > -        return 0;
> > -}
> > -
> > -static int op_sh_create_files(struct super_block *sb, struct dentry *root)
> > -{
> > -	int i, ret = 0;
> > -
> > -	for (i = 0; i < model->num_counters; i++) {
> > -		struct dentry *dir;
> > -		char buf[4];
> > -
> > -		snprintf(buf, sizeof(buf), "%d", i);
> > -		dir = oprofilefs_mkdir(sb, root, buf);
> > -
> > -		ret |= oprofilefs_create_ulong(sb, dir, "enabled", &ctr[i].enabled);
> > -		ret |= oprofilefs_create_ulong(sb, dir, "event", &ctr[i].event);
> > -		ret |= oprofilefs_create_ulong(sb, dir, "kernel", &ctr[i].kernel);
> > -		ret |= oprofilefs_create_ulong(sb, dir, "user", &ctr[i].user);
> > -
> > -		if (model->create_files)
> > -			ret |= model->create_files(sb, dir);
> > -		else
> > -			ret |= oprofilefs_create_ulong(sb, dir, "count", &ctr[i].count);
> > -
> > -		/* Dummy entries */
> > -		ret |= oprofilefs_create_ulong(sb, dir, "unit_mask", &ctr[i].unit_mask);
> > -	}
> > -
> > -	return ret;
> > -}
> > -
> > -static int op_sh_start(void)
> > +static char *op_name_from_perf_name(const char *name)
> >  {
> > -	/* Enable performance monitoring for all counters.  */
> > -	on_each_cpu(model->cpu_start, NULL, 1);
> > +	if (!strcmp(name, "SH-4A"))
> > +		return "sh/sh4a";
> > +	if (!strcmp(name, "SH7750"))
> > +		return "sh/sh7750";
> 
> With that implementation we always have to touch the code for new
> cpus. Maybe we derive it from the perf name, e.g. making all lowercase
> and removing dashes?

Is this code really that bad that we need to start playing string
manipulation games?

> >  
> > -	return 0;
> > -}
> > -
> > -static void op_sh_stop(void)
> > -{
> > -	/* Disable performance monitoring for all counters.  */
> > -	on_each_cpu(model->cpu_stop, NULL, 1);
> > +	return NULL;
> >  }
> >  
> >  int __init oprofile_arch_init(struct oprofile_operations *ops)
> >  {
> > -	struct op_sh_model *lmodel = NULL;
> >  	int ret;
> >  
> >  	/*
> > @@ -91,40 +43,28 @@ int __init oprofile_arch_init(struct oprofile_operations *ops)
> >  	 */
> >  	ops->backtrace = sh_backtrace;
> >  
> > -	/*
> > -	 * XXX
> > -	 *
> > -	 * All of the SH7750/SH-4A counters have been converted to perf,
> > -	 * this infrastructure hook is left for other users until they've
> > -	 * had a chance to convert over, at which point all of this
> > -	 * will be deleted.
> > -	 */
> > -
> > -	if (!lmodel)
> > -		return -ENODEV;
> >  	if (!(current_cpu_data.flags & CPU_HAS_PERF_COUNTER))
> >  		return -ENODEV;
> >  
> > -	ret = lmodel->init();
> > -	if (unlikely(ret != 0))
> > -		return ret;
> > +	ops->setup		= oprofile_perf_setup;
> > +	ops->create_files	= oprofile_perf_create_files;
> > +	ops->start		= oprofile_perf_start;
> > +	ops->stop		= oprofile_perf_stop;
> > +	ops->cpu_type		= op_name_from_perf_name(sh_pmu_name());
> >  
> > -	model = lmodel;
> > +	oprofile_perf_set_num_counters(sh_pmu_num_events());
> >  
> > -	ops->setup		= op_sh_setup;
> > -	ops->create_files	= op_sh_create_files;
> > -	ops->start		= op_sh_start;
> > -	ops->stop		= op_sh_stop;
> > -	ops->cpu_type		= lmodel->cpu_type;
> > +	ret = oprofile_perf_init();
> 
> Instead of exporting all the functions above implement something like:
> 
> 	name = op_name_from_perf_name(sh_pmu_name());
> 	num_events = sh_pmu_num_events();
> 	ret = oprofile_perf_init(ops, name, num_events);
> 
> We will then have only oprofile_perf_init() and oprofile_perf_exit()
> as interface which is much cleaner.

Well, the reason that I left it this way is so that architectures can
choose to implement wrappers around the oprofile_perf_* functions. I
don't think ARM or SH actually need wrappers (the only extra thing that
ARM does is locking which SH should probably do too) but I assumed there
was a reason that these functions pointers were exposed originally. I
haven't look at what other architectures would do. I'll take a look at
that.

WARNING: multiple messages have this Message-ID (diff)
From: matt@console-pimps.org (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 4/4] sh: Use the perf-events backend for oprofile
Date: Fri, 27 Aug 2010 21:19:46 +0100	[thread overview]
Message-ID: <20100827201946.GB18829@console-pimps.org> (raw)
In-Reply-To: <20100827145901.GO22783@erda.amd.com>

On Fri, Aug 27, 2010 at 04:59:01PM +0200, Robert Richter wrote:
> On 26.08.10 15:09:19, Matt Fleming wrote:
> > Use the perf-events based wrapper for oprofile available in
> > drivers/oprofile. This allows us to centralise the code to control
> > performance counters.
> > 
> > Signed-off-by: Matt Fleming <matt@console-pimps.org>
> > ---
> > 
> > Paul,
> > 
> > I dropped the CONFIG_PERF_EVENTS dependency from the Makefile in this
> > version because to do anything useful we need perf events anyway.
> 
> Initialization should simply fail with a printk message for this case,
> implement function stubs for the !CONFIG_PERF_EVENTS case instead in
> the oprofile.h header file.

I didn't do this because I was hoping that eventually we'd make
CONFIG_OPROFILE select PERF_EVENTS. Would you be OK making that change
instead? Runtime failure is best avoided where possible, especially when
we can sort this out at compile time.

> > 
> >  arch/sh/oprofile/Makefile  |    2 +-
> >  arch/sh/oprofile/common.c  |   96 ++++++++-----------------------------------
> >  arch/sh/oprofile/op_impl.h |   33 ---------------
> >  3 files changed, 19 insertions(+), 112 deletions(-)
> >  delete mode 100644 arch/sh/oprofile/op_impl.h
> > 
> > diff --git a/arch/sh/oprofile/Makefile b/arch/sh/oprofile/Makefile
> > index 4886c5c..e1015ae 100644
> > --- a/arch/sh/oprofile/Makefile
> > +++ b/arch/sh/oprofile/Makefile
> > @@ -4,6 +4,6 @@ DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
> >  		oprof.o cpu_buffer.o buffer_sync.o \
> >  		event_buffer.o oprofile_files.o \
> >  		oprofilefs.o oprofile_stats.o \
> > -		timer_int.o )
> > +		timer_int.o oprofile_perf.o )
> >  
> >  oprofile-y	:= $(DRIVER_OBJS) common.o backtrace.o
> > diff --git a/arch/sh/oprofile/common.c b/arch/sh/oprofile/common.c
> > index ac60493..f8d4a84 100644
> > --- a/arch/sh/oprofile/common.c
> > +++ b/arch/sh/oprofile/common.c
> > @@ -17,71 +17,23 @@
> >  #include <linux/init.h>
> >  #include <linux/errno.h>
> >  #include <linux/smp.h>
> > +#include <linux/perf_event.h>
> 
> I don't see a reason why this must be included here.
> 
> It's only for sh_pmu_name() and sh_pmu_num_events(), so the interface
> looks wrong here. It should be in oprofile_perf.c. The functions
> should be generic non-arch perf code. See below.

These functions are inherently architecture-specific. See my reply to
your response to patch 2/4.

> >  #include <asm/processor.h>
> > -#include "op_impl.h"
> > -
> > -static struct op_sh_model *model;
> > -
> > -static struct op_counter_config ctr[20];
> >  
> >  extern void sh_backtrace(struct pt_regs * const regs, unsigned int depth);
> >  
> > -static int op_sh_setup(void)
> > -{
> > -	/* Pre-compute the values to stuff in the hardware registers.  */
> > -	model->reg_setup(ctr);
> > -
> > -	/* Configure the registers on all cpus.  */
> > -	on_each_cpu(model->cpu_setup, NULL, 1);
> > -
> > -        return 0;
> > -}
> > -
> > -static int op_sh_create_files(struct super_block *sb, struct dentry *root)
> > -{
> > -	int i, ret = 0;
> > -
> > -	for (i = 0; i < model->num_counters; i++) {
> > -		struct dentry *dir;
> > -		char buf[4];
> > -
> > -		snprintf(buf, sizeof(buf), "%d", i);
> > -		dir = oprofilefs_mkdir(sb, root, buf);
> > -
> > -		ret |= oprofilefs_create_ulong(sb, dir, "enabled", &ctr[i].enabled);
> > -		ret |= oprofilefs_create_ulong(sb, dir, "event", &ctr[i].event);
> > -		ret |= oprofilefs_create_ulong(sb, dir, "kernel", &ctr[i].kernel);
> > -		ret |= oprofilefs_create_ulong(sb, dir, "user", &ctr[i].user);
> > -
> > -		if (model->create_files)
> > -			ret |= model->create_files(sb, dir);
> > -		else
> > -			ret |= oprofilefs_create_ulong(sb, dir, "count", &ctr[i].count);
> > -
> > -		/* Dummy entries */
> > -		ret |= oprofilefs_create_ulong(sb, dir, "unit_mask", &ctr[i].unit_mask);
> > -	}
> > -
> > -	return ret;
> > -}
> > -
> > -static int op_sh_start(void)
> > +static char *op_name_from_perf_name(const char *name)
> >  {
> > -	/* Enable performance monitoring for all counters.  */
> > -	on_each_cpu(model->cpu_start, NULL, 1);
> > +	if (!strcmp(name, "SH-4A"))
> > +		return "sh/sh4a";
> > +	if (!strcmp(name, "SH7750"))
> > +		return "sh/sh7750";
> 
> With that implementation we always have to touch the code for new
> cpus. Maybe we derive it from the perf name, e.g. making all lowercase
> and removing dashes?

Is this code really that bad that we need to start playing string
manipulation games?

> >  
> > -	return 0;
> > -}
> > -
> > -static void op_sh_stop(void)
> > -{
> > -	/* Disable performance monitoring for all counters.  */
> > -	on_each_cpu(model->cpu_stop, NULL, 1);
> > +	return NULL;
> >  }
> >  
> >  int __init oprofile_arch_init(struct oprofile_operations *ops)
> >  {
> > -	struct op_sh_model *lmodel = NULL;
> >  	int ret;
> >  
> >  	/*
> > @@ -91,40 +43,28 @@ int __init oprofile_arch_init(struct oprofile_operations *ops)
> >  	 */
> >  	ops->backtrace = sh_backtrace;
> >  
> > -	/*
> > -	 * XXX
> > -	 *
> > -	 * All of the SH7750/SH-4A counters have been converted to perf,
> > -	 * this infrastructure hook is left for other users until they've
> > -	 * had a chance to convert over, at which point all of this
> > -	 * will be deleted.
> > -	 */
> > -
> > -	if (!lmodel)
> > -		return -ENODEV;
> >  	if (!(current_cpu_data.flags & CPU_HAS_PERF_COUNTER))
> >  		return -ENODEV;
> >  
> > -	ret = lmodel->init();
> > -	if (unlikely(ret != 0))
> > -		return ret;
> > +	ops->setup		= oprofile_perf_setup;
> > +	ops->create_files	= oprofile_perf_create_files;
> > +	ops->start		= oprofile_perf_start;
> > +	ops->stop		= oprofile_perf_stop;
> > +	ops->cpu_type		= op_name_from_perf_name(sh_pmu_name());
> >  
> > -	model = lmodel;
> > +	oprofile_perf_set_num_counters(sh_pmu_num_events());
> >  
> > -	ops->setup		= op_sh_setup;
> > -	ops->create_files	= op_sh_create_files;
> > -	ops->start		= op_sh_start;
> > -	ops->stop		= op_sh_stop;
> > -	ops->cpu_type		= lmodel->cpu_type;
> > +	ret = oprofile_perf_init();
> 
> Instead of exporting all the functions above implement something like:
> 
> 	name = op_name_from_perf_name(sh_pmu_name());
> 	num_events = sh_pmu_num_events();
> 	ret = oprofile_perf_init(ops, name, num_events);
> 
> We will then have only oprofile_perf_init() and oprofile_perf_exit()
> as interface which is much cleaner.

Well, the reason that I left it this way is so that architectures can
choose to implement wrappers around the oprofile_perf_* functions. I
don't think ARM or SH actually need wrappers (the only extra thing that
ARM does is locking which SH should probably do too) but I assumed there
was a reason that these functions pointers were exposed originally. I
haven't look at what other architectures would do. I'll take a look at
that.

  reply	other threads:[~2010-08-27 20:19 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-26 19:09 [PATCH V2 0/4] Generalise ARM perf-events backend for oprofile Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-26 19:09 ` [PATCH 1/4] oprofile: Handle initialisation failure more gracefully Matt Fleming
2010-08-26 19:09   ` Matt Fleming
2010-08-26 19:09   ` Matt Fleming
2010-08-27 12:43   ` Robert Richter
2010-08-27 12:43     ` Robert Richter
2010-08-27 12:43     ` [PATCH 1/4] oprofile: Handle initialisation failure more Robert Richter
2010-08-27 15:15     ` [PATCH 1/4] oprofile: Handle initialisation failure more gracefully Will Deacon
2010-08-27 15:15       ` Will Deacon
2010-08-27 15:15       ` [PATCH 1/4] oprofile: Handle initialisation failure more Will Deacon
2010-08-27 16:38       ` [PATCH 1/4] oprofile: Handle initialisation failure more gracefully Robert Richter
2010-08-27 16:38         ` Robert Richter
2010-08-27 16:38         ` [PATCH 1/4] oprofile: Handle initialisation failure more Robert Richter
2010-08-27 18:06         ` [PATCH 1/4] oprofile: Handle initialisation failure more gracefully Will Deacon
2010-08-27 18:06           ` Will Deacon
2010-08-27 18:06           ` [PATCH 1/4] oprofile: Handle initialisation failure more Will Deacon
2010-08-27 19:47           ` [PATCH 1/4] oprofile: Handle initialisation failure more gracefully Robert Richter
2010-08-27 19:47             ` Robert Richter
2010-08-27 19:47             ` [PATCH 1/4] oprofile: Handle initialisation failure more Robert Richter
2010-08-26 19:09 ` [PATCH 2/4] sh: Accessor functions for the sh_pmu state Matt Fleming
2010-08-26 19:09   ` Matt Fleming
2010-08-26 19:09   ` Matt Fleming
2010-08-27 13:43   ` Robert Richter
2010-08-27 13:43     ` Robert Richter
2010-08-27 13:43     ` Robert Richter
2010-08-27 19:17     ` Matt Fleming
2010-08-27 19:17       ` Matt Fleming
2010-08-27 19:17       ` Matt Fleming
2010-08-30 12:41       ` Robert Richter
2010-08-30 12:41         ` Robert Richter
2010-08-30 12:41         ` Robert Richter
2010-08-26 19:09 ` [PATCH V2 3/4] oprofile: Abstract the perf-events backend Matt Fleming
2010-08-26 19:09   ` Matt Fleming
2010-08-26 19:09   ` Matt Fleming
2010-08-26 19:09   ` Matt Fleming
2010-08-27 10:41   ` Will Deacon
2010-08-27 10:41     ` Will Deacon
2010-08-27 10:41     ` Will Deacon
2010-08-27 12:44     ` Matt Fleming
2010-08-27 12:44       ` Matt Fleming
2010-08-27 12:44       ` Matt Fleming
2010-08-27 12:59   ` Robert Richter
2010-08-27 12:59     ` Robert Richter
2010-08-27 12:59     ` Robert Richter
2010-08-27 14:31   ` Robert Richter
2010-08-27 14:31     ` Robert Richter
2010-08-27 14:31     ` Robert Richter
2010-08-26 19:09 ` [PATCH V2 4/4] sh: Use the perf-events backend for oprofile Matt Fleming
2010-08-26 19:09   ` Matt Fleming
2010-08-26 19:09   ` Matt Fleming
2010-08-26 19:09   ` Matt Fleming
2010-08-27 14:59   ` Robert Richter
2010-08-27 14:59     ` Robert Richter
2010-08-27 14:59     ` Robert Richter
2010-08-27 20:19     ` Matt Fleming [this message]
2010-08-27 20:19       ` Matt Fleming
2010-08-27 20:19       ` Matt Fleming
2010-08-31 11:28       ` Robert Richter
2010-08-31 11:28         ` Robert Richter
2010-08-31 11:28         ` Robert Richter
2010-08-31 12:23         ` Matt Fleming
2010-08-31 12:23           ` Matt Fleming
2010-08-31 12:23           ` Matt Fleming
2010-08-31 13:26           ` Robert Richter
2010-08-31 13:26             ` Robert Richter
2010-08-31 13:26             ` Robert Richter
2010-08-31 11:05 ` [PATCH V2 0/4] Generalise ARM " Robert Richter
2010-08-31 11:05   ` Robert Richter
2010-08-31 11:05   ` Robert Richter
2010-08-31 11:25   ` Matt Fleming
2010-08-31 11:25     ` Matt Fleming
2010-08-31 11:25     ` Matt Fleming

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=20100827201946.GB18829@console-pimps.org \
    --to=matt@console-pimps.org \
    --cc=acme@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=robert.richter@amd.com \
    --cc=will.deacon@arm.com \
    /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.