Re: [PATCH v8 02/14] perf: Add AUX area to ring buffer for raw data streams

[Alexander Shishkin <alexander.shishkin@linux.intel.com>]

Peter Zijlstra <peterz@infradead.org> writes:

> On Mon, Jan 12, 2015 at 03:12:58PM +0200, Alexander Shishkin wrote:
>> > I suppose we could; I'm trying to remember why I did it like this, I'm
>> > failing to remember much past yesterday atm :/ 
>> 
>> Well, right now we can only map things in one order: user page + perf
>> buffer, then aux buffer. Ideally, we can reduce it to mapping the user
>> page first (always R/W), setting up the desired offsets for data and aux
>> buffers and then mapping those in whatever order. And we can also have
>> holes between them if we want (not sure if that's useful, though).
>
> Indeed, over the weekend I came up a similar argument. Suppose we want
> to extend the thing with yet another area, at that point we simply do
> not know which segment is meant to be mapp()ed.
>
> Breaking up the control page from the data buffer is indeed a sane
> proposal.
>
>> If we want to stick to the current scheme of things where user page is
>> mapped together with data, we should set up aux_{offset,size} in
>> kernel's perf_mmap() path, similarly to data_{offset,size}.
>> 
>> There is another problem with it, though: it makes it impossible to run
>> the aux buffer in "full trace mode" (where we move the tail as we read
>> the data out), while running the data buffer in overwrite mode, because
>> the latter requires the user_page to be mapped RO => no way to update
>> aux_tail for the user.
>
> ISTR aux bits relying on their own mmap(PROT_WRITE) bit, but yes-ish.

It is. Now if data buffer is made to behave the same way, this problem
goes away. Let me see if I can come up with a patch for this, bearing in
mind backwards compatibility with older perfs etc.

Regards,
--
Alex