Re: [RFC PATCH 5/6 v4] perf: Fix race in callchains

[Frederic Weisbecker <fweisbec@gmail.com>]

On Tue, Aug 17, 2010 at 02:53:31PM +1000, Paul Mackerras wrote:
> On Tue, Aug 17, 2010 at 03:34:06AM +0200, Frederic Weisbecker wrote:
> 
> > Now that software events don't have interrupt disabled anymore in
> > the event path, callchains can nest on any context. So seperating
> > nmi and others contexts in two buffers has become racy.
> > 
> > Fix this by providing one buffer per nesting level. Given the size
> > of the callchain entries (2040 bytes * 4), we now need to allocate
> > them dynamically.
> > 
> > v2: Fixed put_callchain_entry call after recursion.
> >     Fix the type of the recursion, it must be an array.
> > 
> > v3: Use a manual pr cpu allocation (temporary solution until NMIs
> >     can safely access vmalloc'ed memory).
> 
> It would be nice to make these allocations node-local.


You're right, I'll use kmalloc_node then.

 
> Also, I see that we're allocating 4 buffers per cpu on powerpc when we
> strictly only need 3, but I don't suppose that really matters.


Yeah, we are allocating a similar per-context bunch of buffers for trace
events and also for software events.

If we had a way to know if an arch has nmis, we could manage that.
Whenever this is about simulated or really unmaskable, we don't care,
we just need to know if events can nest on traditional irq disabled
sections.

How do you deal with that in PPC? Is the event delayed to when irqs are
restored?