All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt@console-pimps.org>
To: Will Deacon <will.deacon@arm.com>
Cc: linux-kernel@vger.kernel.org,
	Robert Richter <robert.richter@amd.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 3/4] oprofile: Abstract the perf-events backend
Date: Fri, 27 Aug 2010 13:44:05 +0100	[thread overview]
Message-ID: <20100827124405.GA23598@console-pimps.org> (raw)
In-Reply-To: <1282905691.16770.20.camel@e102144-lin.cambridge.arm.com>

On Fri, Aug 27, 2010 at 11:41:31AM +0100, Will Deacon wrote:
> Hi Matt,
> 
> I'm still not happy with the init/exit alloc/free code:
> 
> On Thu, 2010-08-26 at 20:09 +0100, Matt Fleming wrote:
> 
> [...]
> 
> > +int oprofile_perf_init(void)
> > +{
> > +       u32 counter_size = sizeof(struct op_counter_config);
> > +       int cpu;
> > +
> > +       counter_config = kcalloc(perf_num_counters, counter_size, GFP_KERNEL);
> > +
> > +       if (!counter_config) {
> > +               pr_info("oprofile: failed to allocate %d "
> > +                               "counters\n", perf_num_counters);
> > +               return -ENOMEM;
> > +       }
> > +
> > +       for_each_possible_cpu(cpu) {
> > +               perf_events[cpu] = kcalloc(perf_num_counters,
> > +                               sizeof(struct perf_event *), GFP_KERNEL);
> > +               if (!perf_events[cpu]) {
> > +                       pr_info("oprofile: failed to allocate %d perf events "
> > +                                       "for cpu %d\n", perf_num_counters, cpu);
> > +                       while (--cpu >= 0)
> > +                               kfree(perf_events[cpu]);
> > +                       kfree(counter_config);
> > +                       return -ENOMEM;
> > +               }
> > +       }
> > +
> > +       return 0;
> > +}
> 
> So here, if the perf_events allocation fails for a cpu, we free the
> stuff we've already allocated [including counter_config] and return
> -ENOMEM. Looking at drivers/oprofile/oprof.c:
> 
> static int __init oprofile_init(void)
> {
> 	int err;
> 
> 	err = oprofile_arch_init(&oprofile_ops);
> 	if (err < 0 || timer) {
> 		printk(KERN_INFO "oprofile: using timer interrupt.\n");
> 		err = oprofile_timer_init(&oprofile_ops);
> 		if (err)
> 			goto out_arch;
> 	}
> 	err = oprofilefs_register();
> 	if (err)
> 		goto out_arch;
> 	return 0;
> 
> out_arch:
> 	oprofile_arch_exit();
> 	return err;
> }
> 
> So now, if timer_init fails or oprofilefs_register fails, we will
> call oprofile_arch_exit, which calls oprofile_perf_exit:
> 
> > +void oprofile_perf_exit(void)
> > +{
> > +       int id, cpu;
> > +
> > +       for_each_possible_cpu(cpu) {
> > +               for (id = 0; id < perf_num_counters; ++id)
> > +                       oprofile_destroy_counter(cpu, id);
> > +
> > +               kfree(perf_events[cpu]);
> > +       }
> > +
> > +       kfree(counter_config);
> > +}
> 
> meaning that we will free everything again! This is what I
> was trying to avoid in patch 1/4, by moving the counter_config
> freeing into the *_exit function. Looking at it again, I think
> all the freeing should be moved to the *_exit function and the init
> function should just return error when allocation fails. What do you
> think?

*facepalm*

I dunno how I forgot to fix up that patch. Sorry. You're completely
right, I forgot to role your changes from patch 1/4 into 3/4 when I
shuffled the code around. Thank you for being diligent.

> > +/*
> > + * Create active perf events based on the perviously configured
> > + * attributes.
> > + */
> 
> typo :)

Thanks.

> For what it's worth, I tested the series on my Cortex-A9 board and
> everything seemed to work fine. I'll give the patches another spin when
> we've sorted out these memory issues.

Excellent news. Thanks for testing! I'll get the next version of patch
3/4 out tonight.

WARNING: multiple messages have this Message-ID (diff)
From: Matt Fleming <matt@console-pimps.org>
To: Will Deacon <will.deacon@arm.com>
Cc: linux-kernel@vger.kernel.org,
	Robert Richter <robert.richter@amd.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 3/4] oprofile: Abstract the perf-events backend
Date: Fri, 27 Aug 2010 12:44:05 +0000	[thread overview]
Message-ID: <20100827124405.GA23598@console-pimps.org> (raw)
In-Reply-To: <1282905691.16770.20.camel@e102144-lin.cambridge.arm.com>

On Fri, Aug 27, 2010 at 11:41:31AM +0100, Will Deacon wrote:
> Hi Matt,
> 
> I'm still not happy with the init/exit alloc/free code:
> 
> On Thu, 2010-08-26 at 20:09 +0100, Matt Fleming wrote:
> 
> [...]
> 
> > +int oprofile_perf_init(void)
> > +{
> > +       u32 counter_size = sizeof(struct op_counter_config);
> > +       int cpu;
> > +
> > +       counter_config = kcalloc(perf_num_counters, counter_size, GFP_KERNEL);
> > +
> > +       if (!counter_config) {
> > +               pr_info("oprofile: failed to allocate %d "
> > +                               "counters\n", perf_num_counters);
> > +               return -ENOMEM;
> > +       }
> > +
> > +       for_each_possible_cpu(cpu) {
> > +               perf_events[cpu] = kcalloc(perf_num_counters,
> > +                               sizeof(struct perf_event *), GFP_KERNEL);
> > +               if (!perf_events[cpu]) {
> > +                       pr_info("oprofile: failed to allocate %d perf events "
> > +                                       "for cpu %d\n", perf_num_counters, cpu);
> > +                       while (--cpu >= 0)
> > +                               kfree(perf_events[cpu]);
> > +                       kfree(counter_config);
> > +                       return -ENOMEM;
> > +               }
> > +       }
> > +
> > +       return 0;
> > +}
> 
> So here, if the perf_events allocation fails for a cpu, we free the
> stuff we've already allocated [including counter_config] and return
> -ENOMEM. Looking at drivers/oprofile/oprof.c:
> 
> static int __init oprofile_init(void)
> {
> 	int err;
> 
> 	err = oprofile_arch_init(&oprofile_ops);
> 	if (err < 0 || timer) {
> 		printk(KERN_INFO "oprofile: using timer interrupt.\n");
> 		err = oprofile_timer_init(&oprofile_ops);
> 		if (err)
> 			goto out_arch;
> 	}
> 	err = oprofilefs_register();
> 	if (err)
> 		goto out_arch;
> 	return 0;
> 
> out_arch:
> 	oprofile_arch_exit();
> 	return err;
> }
> 
> So now, if timer_init fails or oprofilefs_register fails, we will
> call oprofile_arch_exit, which calls oprofile_perf_exit:
> 
> > +void oprofile_perf_exit(void)
> > +{
> > +       int id, cpu;
> > +
> > +       for_each_possible_cpu(cpu) {
> > +               for (id = 0; id < perf_num_counters; ++id)
> > +                       oprofile_destroy_counter(cpu, id);
> > +
> > +               kfree(perf_events[cpu]);
> > +       }
> > +
> > +       kfree(counter_config);
> > +}
> 
> meaning that we will free everything again! This is what I
> was trying to avoid in patch 1/4, by moving the counter_config
> freeing into the *_exit function. Looking at it again, I think
> all the freeing should be moved to the *_exit function and the init
> function should just return error when allocation fails. What do you
> think?

*facepalm*

I dunno how I forgot to fix up that patch. Sorry. You're completely
right, I forgot to role your changes from patch 1/4 into 3/4 when I
shuffled the code around. Thank you for being diligent.

> > +/*
> > + * Create active perf events based on the perviously configured
> > + * attributes.
> > + */
> 
> typo :)

Thanks.

> For what it's worth, I tested the series on my Cortex-A9 board and
> everything seemed to work fine. I'll give the patches another spin when
> we've sorted out these memory issues.

Excellent news. Thanks for testing! I'll get the next version of patch
3/4 out tonight.

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 3/4] oprofile: Abstract the perf-events backend
Date: Fri, 27 Aug 2010 13:44:05 +0100	[thread overview]
Message-ID: <20100827124405.GA23598@console-pimps.org> (raw)
In-Reply-To: <1282905691.16770.20.camel@e102144-lin.cambridge.arm.com>

On Fri, Aug 27, 2010 at 11:41:31AM +0100, Will Deacon wrote:
> Hi Matt,
> 
> I'm still not happy with the init/exit alloc/free code:
> 
> On Thu, 2010-08-26 at 20:09 +0100, Matt Fleming wrote:
> 
> [...]
> 
> > +int oprofile_perf_init(void)
> > +{
> > +       u32 counter_size = sizeof(struct op_counter_config);
> > +       int cpu;
> > +
> > +       counter_config = kcalloc(perf_num_counters, counter_size, GFP_KERNEL);
> > +
> > +       if (!counter_config) {
> > +               pr_info("oprofile: failed to allocate %d "
> > +                               "counters\n", perf_num_counters);
> > +               return -ENOMEM;
> > +       }
> > +
> > +       for_each_possible_cpu(cpu) {
> > +               perf_events[cpu] = kcalloc(perf_num_counters,
> > +                               sizeof(struct perf_event *), GFP_KERNEL);
> > +               if (!perf_events[cpu]) {
> > +                       pr_info("oprofile: failed to allocate %d perf events "
> > +                                       "for cpu %d\n", perf_num_counters, cpu);
> > +                       while (--cpu >= 0)
> > +                               kfree(perf_events[cpu]);
> > +                       kfree(counter_config);
> > +                       return -ENOMEM;
> > +               }
> > +       }
> > +
> > +       return 0;
> > +}
> 
> So here, if the perf_events allocation fails for a cpu, we free the
> stuff we've already allocated [including counter_config] and return
> -ENOMEM. Looking at drivers/oprofile/oprof.c:
> 
> static int __init oprofile_init(void)
> {
> 	int err;
> 
> 	err = oprofile_arch_init(&oprofile_ops);
> 	if (err < 0 || timer) {
> 		printk(KERN_INFO "oprofile: using timer interrupt.\n");
> 		err = oprofile_timer_init(&oprofile_ops);
> 		if (err)
> 			goto out_arch;
> 	}
> 	err = oprofilefs_register();
> 	if (err)
> 		goto out_arch;
> 	return 0;
> 
> out_arch:
> 	oprofile_arch_exit();
> 	return err;
> }
> 
> So now, if timer_init fails or oprofilefs_register fails, we will
> call oprofile_arch_exit, which calls oprofile_perf_exit:
> 
> > +void oprofile_perf_exit(void)
> > +{
> > +       int id, cpu;
> > +
> > +       for_each_possible_cpu(cpu) {
> > +               for (id = 0; id < perf_num_counters; ++id)
> > +                       oprofile_destroy_counter(cpu, id);
> > +
> > +               kfree(perf_events[cpu]);
> > +       }
> > +
> > +       kfree(counter_config);
> > +}
> 
> meaning that we will free everything again! This is what I
> was trying to avoid in patch 1/4, by moving the counter_config
> freeing into the *_exit function. Looking at it again, I think
> all the freeing should be moved to the *_exit function and the init
> function should just return error when allocation fails. What do you
> think?

*facepalm*

I dunno how I forgot to fix up that patch. Sorry. You're completely
right, I forgot to role your changes from patch 1/4 into 3/4 when I
shuffled the code around. Thank you for being diligent.

> > +/*
> > + * Create active perf events based on the perviously configured
> > + * attributes.
> > + */
> 
> typo :)

Thanks.

> For what it's worth, I tested the series on my Cortex-A9 board and
> everything seemed to work fine. I'll give the patches another spin when
> we've sorted out these memory issues.

Excellent news. Thanks for testing! I'll get the next version of patch
3/4 out tonight.

  reply	other threads:[~2010-08-27 12:44 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 [this message]
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
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=20100827124405.GA23598@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.