[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871spdx6jj.fsf@ashishki-desk.ger.corp.intel.com>
Date: Tue, 18 Jul 2017 15:40:00 +0300
From: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To: Alexey Budankov <alexey.budankov@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Andi Kleen <ak@...ux.intel.com>, Kan Liang <kan.liang@...el.com>,
Dmitri Prokhorov <Dmitry.Prohorov@...el.com>,
Valery Cherepennikov <valery.cherepennikov@...el.com>,
Mark Rutland <mark.rutland@....com>,
David Carrillo-Cisneros <davidcc@...gle.com>,
Stephane Eranian <eranian@...gle.com>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 4/4]: perf/core: complete replace of lists by rb trees for pinned and flexible groups at perf_event_context
Alexey Budankov <alexey.budankov@...ux.intel.com> writes:
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 7b2cddf..8e1967f 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -603,13 +603,6 @@ struct perf_event {
> */
> struct list_head group_list;
> /*
> - * Entry into the group_list list above;
> - * the entry may be attached to the self group_list list above
> - * in case the event is directly attached to the tree;
> - */
> - struct list_head group_list_entry;
> -
> - /*
> * We need storage to track the entries in perf_pmu_migrate_context; we
> * cannot use the event_entry because of RCU and we want to keep the
> * group in tact which avoids us using the other two entries.
You probably also want to explain this change, for example change the
@group_list description, saying that something else links into it now.
> @@ -749,15 +742,6 @@ struct perf_event {
> #endif /* CONFIG_PERF_EVENTS */
> };
>
> -/*
> - * event groups keep group leader events arranged as an rb tree with
> - * event->cpu key and as a list for the whole tree iterations;
> - */
> -struct perf_event_groups {
> - struct list_head list;
> - struct rb_root tree;
> -};
Was the @list component ever used? From this patch it looks like it
wasn't and in reality you replaced the lists with trees is 1/4, but left
the lists to hang around for a while.
I think a more generic comment here is that it's difficult to review
patches that don't make sense in separation from one another. It does
make sense to make a transition across several patches, but each patch
kind of needs to make sense on its own. For example, 1/2 adds trees
while keeping the lists intact, 2/2 removes the lists.
Regards,
--
Alex
Powered by blists - more mailing lists