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]
Date:	Mon, 16 Dec 2013 13:08:16 +0200
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jiri Olsa <jolsa@...hat.com>, Mike Galbraith <efault@....de>,
	Namhyung Kim <namhyung@...il.com>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <ak@...ux.intel.com>,
	Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH v0 00/71] perf: Add support for Intel Processor Trace

Ingo Molnar <mingo@...nel.org> writes:

> * Alexander Shishkin <alexander.shishkin@...ux.intel.com> wrote:
>
>> Ingo Molnar <mingo@...nel.org> writes:
>> 
>> > * Alexander Shishkin <alexander.shishkin@...ux.intel.com> wrote:
>> >
>> >> Hi,
>> >> 
>> >> This patchset adds support for Intel Processor Trace (PT) extension 
>> >> [1] of Intel Architecture that allows the capture of information 
>> >> about software execution flow, to the perf kernel and userspace 
>> >> infrastructure. We provide an abstraction for it called "itrace" for 
>> >> "instruction trace" ([2]).
>> >
>> > Ok, this feature looks rather interesting.
>> >
>> > On the hardware side this is essentially BTS (Branch Trace Store) 
>> > on steroids (with many extensions), right?
>> 
>> Yes, you get timestamps and all sorts of other useful data in the 
>> trace and the performance intrusion is much less than that of BTS.
>
> So the problem I see here right now that BTS is rarely used and AFAICS 
> close to unmaintained. It has some very minimal support in 'perf 
> script' but that's all I can see.
>
> So one necessary precondition to merging PT support would be to have a 
> convincing case that this kind of stuff is generally useful.

This is not unreasonable. We can have some of this functionality with
BTS.

> One good approach to do that would be to unify the BTS and PT tooling 
> (the kernel side can be unified as well, to the extent it makes 
> sense), and to prove it via actual functionality that this stuff 
> matters. BTS is available widely, so the tooling can be tested by 
> anyone who's interested.
>
> Allow people to record crashes in core dumps, allow them to look at 
> histograms/spectrograms of BTS/PT traces, zoom in on actual traces, 
> etc. - make it easier to handle this huge amount of data and visualize 
> traces in other ways you find useful, etc.
>
> None of that is done right now via BTS so nobody uses it.

So I can make BTS appear as an "itrace" pmu similarly to PT. One
question that comes to mind is should we then dispose of the old
interface that's used for accessing BTS functionality or make it coexist
with the new one.

Regards,
--
Alex
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ