perf: Remove dead code in buildin-record.c
in [Kernel]
|
From: Arnaldo Carvalho de Melo on 25 Jun 2010 09:20 Em Fri, Jun 25, 2010 at 10:16:59AM +0800, Gui Jianfeng escreveu: > group_fd related code is dead here, remove them. I agree it is dead at the moment, but I think Peter (or was it Ingo at the time?) had a reason for it to live, Peter, care to take a look? - Arnaldo > Signed-off-by: Gui Jianfeng <guijianfeng(a)cn.fujitsu.com> > --- > tools/perf/builtin-record.c | 12 +----------- > 1 files changed, 1 insertions(+), 11 deletions(-) > > diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c > index abaf0f8..84d58b7 100644 > --- a/tools/perf/builtin-record.c > +++ b/tools/perf/builtin-record.c > @@ -45,7 +45,6 @@ static int freq = 1000; > static int output; > static int pipe_output = 0; > static const char *output_name = "perf.data"; > -static int group = 0; > static int realtime_prio = 0; > static bool raw_samples = false; > static bool system_wide = false; > @@ -203,8 +202,6 @@ static void sig_atexit(void) > kill(getpid(), signr); > } > > -static int group_fd; > - > static struct perf_header_attr *get_header_attr(struct perf_event_attr *a, int nr) > { > struct perf_header_attr *h_attr; > @@ -291,7 +288,7 @@ static void create_counter(int counter, int cpu) > for (thread_index = 0; thread_index < thread_num; thread_index++) { > try_again: > fd[nr_cpu][counter][thread_index] = sys_perf_event_open(attr, > - all_tids[thread_index], cpu, group_fd, 0); > + all_tids[thread_index], cpu, -1, 0); > > if (fd[nr_cpu][counter][thread_index] < 0) { > int err = errno; > @@ -359,12 +356,6 @@ try_again: > assert(fd[nr_cpu][counter][thread_index] >= 0); > fcntl(fd[nr_cpu][counter][thread_index], F_SETFL, O_NONBLOCK); > > - /* > - * First counter acts as the group leader: > - */ > - if (group && group_fd == -1) > - group_fd = fd[nr_cpu][counter][thread_index]; > - > if (counter || thread_index) { > ret = ioctl(fd[nr_cpu][counter][thread_index], > PERF_EVENT_IOC_SET_OUTPUT, > @@ -406,7 +397,6 @@ static void open_counters(int cpu) > { > int counter; > > - group_fd = -1; > for (counter = 0; counter < nr_counters; counter++) > create_counter(counter, cpu); > > -- 1.6.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 25 Jun 2010 10:50 On Fri, 2010-06-25 at 10:13 -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Jun 25, 2010 at 10:16:59AM +0800, Gui Jianfeng escreveu: > > group_fd related code is dead here, remove them. > > I agree it is dead at the moment, but I think Peter (or was it Ingo at > the time?) had a reason for it to live, Peter, care to take a look? Ah, yes, it would be nice for SH (which doesn't have a PMI) to couple a software timer with their hardware counter to get samples. Never got around to actually implementing that though, maybe Paul has a minion interested in making that work? > > Signed-off-by: Gui Jianfeng <guijianfeng(a)cn.fujitsu.com> > > --- > > tools/perf/builtin-record.c | 12 +----------- > > 1 files changed, 1 insertions(+), 11 deletions(-) > > > > diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c > > index abaf0f8..84d58b7 100644 > > --- a/tools/perf/builtin-record.c > > +++ b/tools/perf/builtin-record.c > > @@ -45,7 +45,6 @@ static int freq = 1000; > > static int output; > > static int pipe_output = 0; > > static const char *output_name = "perf.data"; > > -static int group = 0; > > static int realtime_prio = 0; > > static bool raw_samples = false; > > static bool system_wide = false; > > @@ -203,8 +202,6 @@ static void sig_atexit(void) > > kill(getpid(), signr); > > } > > > > -static int group_fd; > > - > > static struct perf_header_attr *get_header_attr(struct perf_event_attr *a, int nr) > > { > > struct perf_header_attr *h_attr; > > @@ -291,7 +288,7 @@ static void create_counter(int counter, int cpu) > > for (thread_index = 0; thread_index < thread_num; thread_index++) { > > try_again: > > fd[nr_cpu][counter][thread_index] = sys_perf_event_open(attr, > > - all_tids[thread_index], cpu, group_fd, 0); > > + all_tids[thread_index], cpu, -1, 0); > > > > if (fd[nr_cpu][counter][thread_index] < 0) { > > int err = errno; > > @@ -359,12 +356,6 @@ try_again: > > assert(fd[nr_cpu][counter][thread_index] >= 0); > > fcntl(fd[nr_cpu][counter][thread_index], F_SETFL, O_NONBLOCK); > > > > - /* > > - * First counter acts as the group leader: > > - */ > > - if (group && group_fd == -1) > > - group_fd = fd[nr_cpu][counter][thread_index]; > > - > > if (counter || thread_index) { > > ret = ioctl(fd[nr_cpu][counter][thread_index], > > PERF_EVENT_IOC_SET_OUTPUT, > > @@ -406,7 +397,6 @@ static void open_counters(int cpu) > > { > > int counter; > > > > - group_fd = -1; > > for (counter = 0; counter < nr_counters; counter++) > > create_counter(counter, cpu); > > > > -- 1.6.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matt Fleming on 26 Jun 2010 11:20 On Fri, 25 Jun 2010 16:48:05 +0200, Peter Zijlstra <peterz(a)infradead.org> wrote: > > Ah, yes, it would be nice for SH (which doesn't have a PMI) to couple a > software timer with their hardware counter to get samples. > > Never got around to actually implementing that though, maybe Paul has a > minion interested in making that work? I'll take a look at it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 26 Jun 2010 14:20 Em Sat, Jun 26, 2010 at 04:14:46PM +0100, Matt Fleming escreveu: > On Fri, 25 Jun 2010 16:48:05 +0200, Peter Zijlstra <peterz(a)infradead.org> wrote: > > Ah, yes, it would be nice for SH (which doesn't have a PMI) to couple a > > software timer with their hardware counter to get samples. > > > > Never got around to actually implementing that though, maybe Paul has a > > minion interested in making that work? > > I'll take a look at it. Thanks! - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matt Fleming on 18 Jul 2010 16:10 On Sat, 26 Jun 2010 16:14:46 +0100, Matt Fleming <matt(a)console-pimps.org> wrote: > On Fri, 25 Jun 2010 16:48:05 +0200, Peter Zijlstra <peterz(a)infradead.org> wrote: > > > > Ah, yes, it would be nice for SH (which doesn't have a PMI) to couple a > > software timer with their hardware counter to get samples. > > > > Never got around to actually implementing that though, maybe Paul has a > > minion interested in making that work? > > I'll take a look at it. How does the 'group_fd' parameter relate to the lack of PMI? Is the idea to have one hrtimer that, when it fires, we sample all the counters? So the first counter to be created is the group leader, which starts the hrtimer, and all other counters are linked to this one? I had a go at using a hrtimer per counter (minus any weighting of samples) and it worked OK and seemed sensible given that we may want to sample counters at different frequencies. Is this what you had in mind with the 'group_fd' paramter, Peter? That there'd be only one hrtimer? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Next
|
Last
Pages: 1 2 Prev: [PATCH 2/5] cpumask: make task_struct.cpus_allowed a cpumask_var_t Next: reply ASAP!!! |