linux-kernel - Re: [PATCH v0 04/71] itrace: Infrastructure for instruction flow tracing units

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, 06 Jan 2014 13:25:02 -0800
From:	Andi Kleen <andi@...stfloor.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Ingo Molnar <mingo@...nel.org>,
	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>
Subject: Re: [PATCH v0 04/71] itrace: Infrastructure for instruction flow tracing units

Peter Zijlstra <peterz@...radead.org> writes:

> On Thu, Dec 19, 2013 at 04:30:53PM +0200, Alexander Shishkin wrote:
>> So I'd like to steer away from the ways in which hardware can be broken
>> and talk about a usable interface, to begin with.
>
> Just dump it into the regular one buffer like I outlined.

Just getting back to this. 

Do you realize that PT buffers have to be page aligned. 

So to mix it with a regular perf buffer would need padding every PT
message by 4K, which wastes a lot of memory. The side band messages
are usually only a few bytes (e.g. context switch).

If the sideband is mfrequent it could even take up >half of the buffer,
but mostly only with padding.

Is that what you intended?

perf doesn't support gaps today, so your proposal wouldn't even
seem to fit into the current perf design.

Also of course it requires disabling/enabling PT explicitly for 
every perf message, which is slow. So you add at least 2*WRMSR cost
(thousands of cycles).

> That said; we very much need to have at least two architectures
> implemented for any of this code to move.
>
> But we cannot ignore the hardware trainwreck; we cannot shape our
> interface around something that's utterly broken.
>
> Some hardware is just too broken to support.

I don't think the PT design is broken in any way, it's straight 
forward and simple.

Trying to mix hardware tracing and software tracing in the same buffer
on the other hand ...

Anyways if perf is not flexible enough to support this I suppose
it could switch to a simple device driver, and only run perf with
separate fds for side band purposes. 

Would you prefer that?

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only
--
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/