[PATCH 0/2]: Get perf counters working on D-cache aliasing cpus.

[PATCH 0/2]: Get perf counters working on D-cache aliasing cpus.

[David Miller]

With Jen's Axboe's basic sparc counter patch in my tree I started
playing with it on sparc64.  Turns out it won't work on anything
pre-Niagara.

The issue is D-cache aliasing between the kernel side mapping
and the user side mapping of the perf event ring buffer.

The following two patches attempt to address this issue and
are working properly on my test machine.

Re: [PATCH 0/2]: Get perf counters working on D-cache aliasing cpus.

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> With Jen's Axboe's basic sparc counter patch in my tree I started 
> playing with it on sparc64.  Turns out it won't work on anything 
> pre-Niagara.
> 
> The issue is D-cache aliasing between the kernel side mapping and 
> the user side mapping of the perf event ring buffer.
> 
> The following two patches attempt to address this issue and are 
> working properly on my test machine.

Oh, great!

The only (small) worry would be that this uses vmalloc space on 
32-bit platforms which is generally a scarce resource.

IMHO it's not a big issue as the typical workflow would be to have 
just a handful of perf ring-buffers around and most of the 
performance work happens in the 64-bit space anyway.

One practical complication is lots of tracepoints and perf trace: 
but we can solve that via output buffer multiplexing: 
PERF_COUNTER_IOC_SET_OUTPUT - which is implemented in 
tip:perfcounters/core but not yet propagated to the tools. That 
would be desirable to do anyway, to enable time-coherent trace 
entries, etc.

	Ingo

Re: [PATCH 0/2]: Get perf counters working on D-cache aliasing cpus.

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Tue, 8 Sep 2009 14:36:10 +0200

> The only (small) worry would be that this uses vmalloc space on 
> 32-bit platforms which is generally a scarce resource.

Yes, I considered this too.

But as you said there are things that mitigate how much of
a real issue this actually is.

Re: [PATCH 0/2]: Get perf counters working on D-cache aliasing cpus.

[Peter Zijlstra]

On Tue, 2009-09-08 at 05:10 -0700, David Miller wrote:
> With Jen's Axboe's basic sparc counter patch in my tree I started
> playing with it on sparc64.  Turns out it won't work on anything
> pre-Niagara.
> 
> The issue is D-cache aliasing between the kernel side mapping
> and the user side mapping of the perf event ring buffer.
> 
> The following two patches attempt to address this issue and
> are working properly on my test machine.

Dave,

Ingo just reminded me that we might want to do splice support for perf
stuff. My plan was to have the splice thing allocate a new page, flip
with a filled one from the buffer and send the filled one down to the
splice consumer.

Now having vmap'ed all that complicates stuff enourmously.

Would it also work if we use order-1 pages on your platform instead of
order-0, so that they are properly aligned for the d-cache?

Re: [PATCH 0/2]: Get perf counters working on D-cache aliasing cpus.

[David Miller]

From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Fri, 18 Sep 2009 14:31:36 +0200

> Ingo just reminded me that we might want to do splice support for perf
> stuff. My plan was to have the splice thing allocate a new page, flip
> with a filled one from the buffer and send the filled one down to the
> splice consumer.
> 
> Now having vmap'ed all that complicates stuff enourmously.
> 
> Would it also work if we use order-1 pages on your platform instead of
> order-0, so that they are properly aligned for the d-cache?

You still have to make sure the order-1 page is order-1 virtually
aligned in userspace.  But that would help only sparc64 because
SHMLBA happens to be 16K (2 * smallest supported PAGE_SIZE).

So, this won't handle sparc32 where the SHMLBA is 4MB.

MIPS has the same exact problems and has a large SHMLBA too.

Re: [PATCH 0/2]: Get perf counters working on D-cache aliasing cpus.

[Peter Zijlstra]

On Fri, 2009-09-18 at 10:22 -0700, David Miller wrote:
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Fri, 18 Sep 2009 14:31:36 +0200
> 
> > Ingo just reminded me that we might want to do splice support for perf
> > stuff. My plan was to have the splice thing allocate a new page, flip
> > with a filled one from the buffer and send the filled one down to the
> > splice consumer.
> > 
> > Now having vmap'ed all that complicates stuff enourmously.
> > 
> > Would it also work if we use order-1 pages on your platform instead of
> > order-0, so that they are properly aligned for the d-cache?
> 
> You still have to make sure the order-1 page is order-1 virtually
> aligned in userspace.  But that would help only sparc64 because
> SHMLBA happens to be 16K (2 * smallest supported PAGE_SIZE).
> 
> So, this won't handle sparc32 where the SHMLBA is 4MB.
> 
> MIPS has the same exact problems and has a large SHMLBA too.

Ah, ok, vmalloc it is then. I'll have to come up with another scheme for
splice() then.

Thanks!