Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

[Alexander Shishkin]

Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes:

> On Fri, Sep 23, 2016 at 05:27:22PM +0300, Alexander Shishkin wrote:
>> > Afaict there's no actual need to hide the AUX buffer for this sampling
>> > stuff; the user knows about all this and can simply mmap() the AUX part.
>> 
>> Yes, you're right here. We could also re-use the AUX record, adding a
>> new flag for this. It may be even better if I can work out the
>> inheritance (the current code doesn't handle inheritance at the moment
>> in case we decide to scrap it).
>
> What is the exact problem with inheritance? You can inherit PT (and
> other) events just fine, and their output redirects to the original
> (AUX) buffer too.
>
> Is the problem untangling which part of the AUX buffer belongs to which
> task upon sample?

Tasks we can figure out from id samples on RECORD_AUX (assuming we're
using those), but which event (if you have multiple) does a sample
belong to is trickier.

Cutting out samples becomes more interesting as normally RECORD_AUX
don't overlap, we can keep it that way and then the samples will
naturally be non-overlapping, but will all be different sizes. And there
is a question of waking up the consumer often enough to copy out all the
samples before the buffer overwrites itself. Let me think a bit.

Regards,
--
Alex