[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinsEANHEicdjOaE6jwUa0bVqH5PBwuGQ3_L59hT@mail.gmail.com>
Date: Tue, 11 May 2010 16:04:17 +0200
From: Stephane Eranian <eranian@...gle.com>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Frédéric Weisbecker <fweisbec@...il.com>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
mingo@...e.hu, Paul Mackerras <paulus@...ba.org>,
"David S. Miller" <davem@...emloft.net>,
perfmon2-devel@...ts.sf.net
Subject: [RFC] perf: perf record sets inherit by default
Hi,
I am confused by the inheritance cmd line option of perf record:
$ perf record -h
usage: perf record [<options>] [<command>]
or: perf record [<options>] -- <command> [<options>]
-e, --event <event> event selector. use 'perf list' to list
available events
--filter <filter>
event filter
-p, --pid <n> record events on existing process id
-t, --tid <n> record events on existing thread id
-r, --realtime <n> collect data with this RT SCHED_FIFO priority
-R, --raw-samples collect raw sample records from all opened counters
-a, --all-cpus system-wide collection from all CPUs
-A, --append append to the output file to do incremental profiling
-C, --profile_cpu <n>
CPU to profile on
-f, --force overwrite existing data file (deprecated)
-c, --count event period to sample
-o, --output <file> output file name
-i, --inherit child tasks inherit counters
This leads to believe that by default inheritance in children is off.
However, builtin-record.c says:
static bool inherit = true;
If that's the case, what's the point of the -i option?
Another side effect of inheritance is that in per-thread mode,
perf creates as many "sessions" as you have CPUs. So
on a 16-way processor, sampling on cycles, perf creates
16 events and 16 x 2-page sampling buffers. That's a lot of
resources consumed if I am just interested in monitoring
a single-threaded workload.
Am I missing something here?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists