[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190708162115.GF3419@hirez.programming.kicks-ass.net>
Date: Mon, 8 Jul 2019 18:21:15 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Ian Rogers <irogers@...gle.com>
Cc: Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
linux-kernel@...r.kernel.org,
Kan Liang <kan.liang@...ux.intel.com>,
Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH 2/7] perf/cgroup: order events in RB tree by cgroup id
On Mon, Jul 01, 2019 at 11:59:50PM -0700, Ian Rogers wrote:
> +#ifndef CONFIG_CGROUP_PERF
> + /*
> + * Without cgroups, with a task context, iterate over per-CPU and any
> + * CPU events.
> + */
> + const int max_itrs = 2;
> +#else
> + /*
> + * The depth of cgroups is limited by MAX_PATH. It is unlikely that this
> + * many parent-child related cgroups will have perf events
> + * monitored. Limit the number of cgroup iterators to 16.
> + */
> + const int max_cgroups_with_events_depth = 16;
> + /*
> + * With cgroups we either iterate for a task context (per-CPU or any CPU
> + * events) or for per CPU the global and per cgroup events.
> + */
> + const int max_itrs = max(2, 1 + max_cgroups_with_events_depth);
That seems like a very complicated way to write 17.
> +#endif
> + /* The number of iterators in use. */
> + int num_itrs;
> + /*
> + * A set of iterators, the iterator for the visit is chosen by the
> + * group_index.
> + */
> + struct perf_event *itrs[max_itrs];
And that is 136 bytes of stack. Which I suppose is just about
acceptible.
But why not something like:
struct perf_event *iters[IS_ENABLED(CONFIG_CGROUP_PERF) ? 17 : 2];
iters[i++] = foo;
WARN_ON_ONCE(i >= ARRAY_SIZE(iters));
?
Powered by blists - more mailing lists