Messages in this thread | | | From | Alexander Shishkin <> | Subject | Re: [PATCH v8 02/14] perf: Add AUX area to ring buffer for raw data streams | Date | Mon, 12 Jan 2015 16:00:28 +0200 |
| |
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
| |