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

[Peter Zijlstra]

On Mon, May 19, 2014 at 03:57:37PM +0300, Alexander Shishkin wrote:
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/