linux-kernel - Re: [PATCH 0/7] perf stat: Change event enable code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151208135336.GE11564@kernel.org>
Date:	Tue, 8 Dec 2015 10:53:36 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Adrian Hunter <adrian.hunter@...el.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>
Subject: Re: [PATCH 0/7] perf stat: Change event enable code

Em Tue, Dec 08, 2015 at 09:29:51AM +0200, Adrian Hunter escreveu:
> On 07/12/15 23:09, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Dec 03, 2015 at 10:06:39AM +0100, Jiri Olsa escreveu:
> >> while testing ftrace:function event I noticed we create
> >> stat counters as enabled (except for enable_on_exec couters).
> >>
> >> This way we count also filter setup and other config code
> >> which might be crucial for some events.
> >>
> >> Posponing the events enable once everything is ready.
> >>
> >> The last patch is RFC as I wasn't sure there's some hidden
> >> catch about perf_evlist__(enable|disable)_event functions
> >> I missed.. Adrian?

> > They look the same, Adrian?

> > Applied the first 6, will give some more time to Adrian to chime in.
 
> Looks like there might already be a problem using evsel->threads instead of
> evlist->threads with the logic relating to evsel->system_wide getting lost -
> but that happened already in "perf evlist: Factor
> perf_evlist__(enable|disable) functions".  Probably the threads should not
> be propagated in that case, but it needs more investigation.  I will try to
> look at it today.

Thanks! Is that covered by any 'perf test' entry? Do you think having
some sort of Intel PT test to run on capable machines would be feasible?

- Arnaldo
--
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/