[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170619152151.GB23705@tassilo.jf.intel.com>
Date: Mon, 19 Jun 2017 08:21:51 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Mark Rutland <mark.rutland@....com>
Cc: Alexey Budankov <alexey.budankov@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Kan Liang <kan.liang@...el.com>,
Dmitri Prokhorov <Dmitry.Prohorov@...el.com>,
Valery Cherepennikov <valery.cherepennikov@...el.com>,
David Carrillo-Cisneros <davidcc@...gle.com>,
Stephane Eranian <eranian@...gle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/n] perf/core: addressing 4x slowdown during
per-process profiling of STREAM benchmark on Intel Xeon Phi
> I was trying to get a feel for how that compares to what we can do
> today. For other reasons (e.g. fd exhaustion), opening NR_CPUS * n
You just have to increase the fd limit. The 1024 fd default is just
archaic for larger systems and doesn't really make any sense because
it only controls very small amounts of kernel memory.
> events might not be a great idea on systems with a huge number of CPUs.
> We might want a heuristic in the perf tool regardless.
But there's no alternative: we have to measure all CPUs with all events.
-andi
Powered by blists - more mailing lists