On Thu, May 08, 2014 at 03:46:36PM +0300, Alexander Shishkin wrote:
> Peter Zijlstra writes:
>
> > On Thu, May 08, 2014 at 03:34:17PM +0300, Alexander Shishkin wrote:
> >> Peter Zijlstra writes:
> >>
> >> > So the aux_head/tail values should also be in the file space and not
> >> > start at 0 a
Peter Zijlstra writes:
> On Thu, May 08, 2014 at 03:34:17PM +0300, Alexander Shishkin wrote:
>> Peter Zijlstra writes:
>>
>> > So the aux_head/tail values should also be in the file space and not
>> > start at 0 again, similar for the offsets in the AUX record.
>>
>> Thinking some more about i
On Thu, May 08, 2014 at 03:34:17PM +0300, Alexander Shishkin wrote:
> Peter Zijlstra writes:
>
> > So the aux_head/tail values should also be in the file space and not
> > start at 0 again, similar for the offsets in the AUX record.
>
> Thinking some more about it: if we keep aux_{offset,size} i
Peter Zijlstra writes:
> So the aux_head/tail values should also be in the file space and not
> start at 0 again, similar for the offsets in the AUX record.
Thinking some more about it: if we keep aux_{offset,size} in userpg,
then it would make sense to have aux_{head,tail} run from 0 to infinit
Alexander Shishkin writes:
> Peter Zijlstra writes:
>
>> How about something like this for the itrace thing?
>
> It's much nicer than the page swizzling draft I was about to send you.
>
>> You would mmap() the regular buffer; when write ->aux_{offset,size} in
>> the control page. After which you
Peter Zijlstra writes:
> How about something like this for the itrace thing?
It's much nicer than the page swizzling draft I was about to send you.
> You would mmap() the regular buffer; when write ->aux_{offset,size} in
> the control page. After which you can do a second mmap() with the .pgoff
Peter Zijlstra writes:
> On Wed, May 07, 2014 at 02:08:43PM -0700, Andi Kleen wrote:
>> > Then, when data inside that aux data store changes they should inject an
>> > PERF_RECORD_AUX to indicate this did happen, which ties it back into the
>> > normal event flow.
>>
>> What happens when the aux
On Wed, May 07, 2014 at 02:08:43PM -0700, Andi Kleen wrote:
> > Then, when data inside that aux data store changes they should inject an
> > PERF_RECORD_AUX to indicate this did happen, which ties it back into the
> > normal event flow.
>
> What happens when the aux buffer wraps? How would the cli
> Then, when data inside that aux data store changes they should inject an
> PERF_RECORD_AUX to indicate this did happen, which ties it back into the
> normal event flow.
What happens when the aux buffer wraps? How would the client know
if the data belongs to this _AUX entry or some later one?
Ma
* Peter Zijlstra wrote:
> How about something like this for the itrace thing?
>
> You would mmap() the regular buffer; when write ->aux_{offset,size}
> in the control page. After which you can do a second mmap() with the
> .pgoff matching the aux_offset you gave and .length matching the
> au
How about something like this for the itrace thing?
You would mmap() the regular buffer; when write ->aux_{offset,size} in
the control page. After which you can do a second mmap() with the .pgoff
matching the aux_offset you gave and .length matching the aux_size you
gave.
This way the mmap() co
Andi Kleen writes:
>> I really don't want the multi-buffer nonsense proposed.
>
>> An event gets
>> _1_ buffer, that's it.
>
> But we already have multi buffer. Just profile multiple CPUs
> Then you have one buffer per CPU that need to be combined.
>
> This just has two buffers per CPU.
Well, a
> > The other big problem is scalability. Even if it was somehow possible
> > to make this scheme work the IPIs for flushing would kill performance
> > on any multi threaded client. Given perf is not multi-threaded today, but
> > it doesn't seem a good idea to design the interface assuming no cli
> I really don't want the multi-buffer nonsense proposed.
> An event gets
> _1_ buffer, that's it.
But we already have multi buffer. Just profile multiple CPUs
Then you have one buffer per CPU that need to be combined.
This just has two buffers per CPU.
> That also means that if someone redire
On Mon, Mar 10, 2014 at 10:24:40AM -0700, Andi Kleen wrote:
> > > Wouldn't we have to teach a ton of code how to be IRQ safe for this to
> > > work? Just step one: how do we go modifying page tables safely from an
> > > interrupt? mm->page_table_lock is a plain non-irq spinlock.
> >
> > Yes, thi
On Wed, Feb 19, 2014 at 02:02:36PM -0800, Dave Hansen wrote:
> On 02/17/2014 06:33 AM, Peter Zijlstra wrote:
> > Then write the PERF_RECORD_DATA structure into the normal ring-buffer
> > location; set data_offset to point to the first page boundary, data_size
> > to 1mb.
> >
> > Then frob things s
On Mon, Feb 17, 2014 at 06:36:59PM -0800, Andi Kleen wrote:
> > I'm not convinced it needs to be a PERF_RECORD_SAMPLE; but some
> > PERF_RECORD_* type for sure.
>
> Adding a header shouldn't be a problem, it's merely wasting 4K.
>
> > Also it must allow interleaving with other > events.
>
> But
> > Wouldn't we have to teach a ton of code how to be IRQ safe for this to
> > work? Just step one: how do we go modifying page tables safely from an
> > interrupt? mm->page_table_lock is a plain non-irq spinlock.
>
> Yes, this does look more than just tricky even if we move the bulk of
> interr
Dave Hansen writes:
> On 02/17/2014 06:33 AM, Peter Zijlstra wrote:
>> Then write the PERF_RECORD_DATA structure into the normal ring-buffer
>> location; set data_offset to point to the first page boundary, data_size
>> to 1mb.
>>
>> Then frob things such that perf_mmap_to_page() for the next 1m
On 02/17/2014 06:33 AM, Peter Zijlstra wrote:
> Then write the PERF_RECORD_DATA structure into the normal ring-buffer
> location; set data_offset to point to the first page boundary, data_size
> to 1mb.
>
> Then frob things such that perf_mmap_to_page() for the next 1mb of pages
> points to your b
> I'm not convinced it needs to be a PERF_RECORD_SAMPLE; but some
> PERF_RECORD_* type for sure.
Adding a header shouldn't be a problem, it's merely wasting 4K.
> Also it must allow interleaving with other > events.
But can you describe a concrete use case where interleaving is better?
I'm not
On Thu, Feb 06, 2014 at 12:50:26PM +0200, Alexander Shishkin wrote:
> Currently, a perf event can have one ring buffer associated with it, that
> is used for perf record stream. However, some pmus, such as instruction
> tracing units, will generate binary streams of their own, for which it is
> con
22 matches
Mail list logo
