[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160217145552.GC15386@kernel.org>
Date: Wed, 17 Feb 2016 11:55:52 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Jiri Olsa <jolsa@...hat.com>
Cc: Jiri Olsa <jolsa@...nel.org>, lkml <linux-kernel@...r.kernel.org>,
David Ahern <dsahern@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Stephane Eranian <eranian@...gle.com>,
Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 01/23] perf record: Add --all-user/--all-kernel options
Em Wed, Feb 17, 2016 at 03:39:38PM +0100, Jiri Olsa escreveu:
> On Tue, Feb 16, 2016 at 01:56:01PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Feb 15, 2016 at 09:34:31AM +0100, Jiri Olsa escreveu:
> > > Allow user to easily switch all events to user or
> > > kernel space with simple --all-user or --all-kernel
> > > options.
> > >
> > > This will be handy within perf mem/c2c wrappers to
> > > switch easily monitoring modes.
> >
> > Humm, some oddities:
> >
> > # perf record --all-user -e cycles -a
> > # perf report --tui # And then notice there are some kernel samples, zoom into kernel DSO
> > Samples: 7 of event 'cycles', Event count (approx.): 3158810, DSO: [kernel.vmlinux]
> > Overhead Comman Symbol
> > 84.05% chrome [k] page_fault
> > 15.73% chrome [k] entry_SYSCALL_64
> > 0.22% chrome [k] apic_timer_interrupt
> >
> > Ditto when using --all-kernel, some userspace samples are there, also perhaps we
> > should show "cycles:u" or "cycles:k" when this --all-user or --all-kernel features
> > are used.
> >
> > Need to investigate why there are kernel samples when --all-user is used and
> > the other way around as well.
> >
> > Also if I use both it quietly accepts and shows just one of them, I guess we
> > should bail out in case someone tries both.
>
> right, that should be handled with warning and exit
> I'll do it in next version
Ok, so I'll wait for it then,
builtin-probe.c uses things like:
set_option_flag(options, 'a', "add", PARSE_OPT_EXCLUSIVE);
set_option_flag(options, 'd', "del", PARSE_OPT_EXCLUSIVE);
We have:
#define OPT_BOOLEAN_FLAG(s, l, v, h, f) { .type = OPTION_BOOLEAN,
.short_name = (s), .long_name = (l), .value = check_vtype(v, bool *),
.help = (h), .flags = (f) }
That allows setting that PARSE_OPT_EXCLUSIVE flag, but we don't have
_FLAG variants for all opt types, for instance there is no
OPT_CALLBACK_FLAG() that could be used in builtin-probe.c to avoid those
unconditional set_option_flag(EXCLUSIVE) :-\
- Arnaldo
Powered by blists - more mailing lists