linux-kernel - Re: [RFC 2/2] perf: add AUX area to ring buffer for raw data streams

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:	Tue, 20 May 2014 11:51:02 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [RFC 2/2] perf: add AUX area to ring buffer for raw data streams

On Mon, May 19, 2014 at 03:57:37PM +0300, Alexander Shishkin wrote:
> Peter Zijlstra <peterz@...radead.org> writes:

> > I'm not entirely thrilled to expose it to the PMU like this.. I realize
> > you want this in order to get physically contiguous pages.
> 
> Hmm, I guess we can have code in perf core to carry out the allocation
> according to, say, contstraint flags and pass the page array down to the
> PMU if that sounds like a cleaner thing to do?
> 
> > Are you aware of allocation constraints for other architectures?
> 
> Somewhat. ARM's trace memory controller supports both scatter-gather and
> a plain contiguous buffer, I haven't found evidence of one being
> available while the other one isn't, so I'm inclined to assume that if
> it can write to system memory, it supports SG.

I've just added a patch from Vince Weaver:

  http://lkml.kernel.org/r/alpine.DEB.2.10.1405161708060.11099@vincent-weaver-1.umelst.maine.edu

That adds pmu::capabilities, I suppose we could start with something
like:

  PERF_PMU_CAP_AUX_BROKEN_SG

which would make the allocator attempt to fill the AUX buffer with as
big a chunks of contiguous memory as is available.

> > That appears to be missing a is_power_of_2(aux_size) check.
> >
> > The problem with not having that is that since
> > perf_event_mmap_page::aux_{head,tail} are of Z mod 2^64 but your actual
> > {head,tail} are of Z mod aux_size, you need aux_size to be a full
> > divider of 2^64 or otherwise you get wrapping issues at the overflow.
> >
> > Having it them all 2^n makes the divider trivial.
> 
> I left it out so that the PMU callback could decide if it wants to do
> the math or not. Maybe it can also be a constraint flag or is it not
> worth it at all?

I'd start with the most constrained model -- that is add the power of
two test -- and worry about relaxing it if it turns out its really
needed.
--
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/