RE: [discuss] BTS overflow handling, was: [PATCH] perf_counter: Fix a race on perf_counter_ctx

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

On Tue, 2009-09-01 at 15:27 +0100, Metzger, Markus T wrote:

> >> >> I do need 3 buffers of 2048 entries = 3x48 pages per cpu, though.
> >> >
> >> >And those pages have to be contiguous too, right? That's an order-6
> >> >alloc, painful.
> >>
> >>
> >> According to an earlier discussion with Roland, they don't have to.
> >> They still need to be locked, though.
> >> According to some other discussion with Andrew and Ingo, I still use
> >> kmalloc to allocate those buffers.
> >
> >Section 18.18.5 of book 3B says the DS buffer base is a linear address.
> >This suggests each buffer does need contiguous pages.
> >
> >48 contiguous pages constitutes an order-6 allocation (64 pages), which
> >is unreliable at best.
> 
> Roland argued that this means virtually contiguous, not physically.

Sure it does, but either you use the linear kernel map, or use vmap.

vmap doesn't sound like very good idea.

> >> When I use schedule_work() instead, how would I ensure that the work is done
> >> before the traced (or tracing) task is rescheduled?
> >
> >No, basically the only thing left is softirqs, which can be preempted by
> >hardirqs, but that's a horrid hack too, esp since processing the BTS
> >outside of the handler will basically result in the BTS tracing its own
> >processing, generating even more data to process.
> 
> I would have disabled perf on that cpu; it won't work, otherwise,
> since the draining code alone would generate more trace than fits into
> a buffer. I would need to disable preemption, though.
> 
> Are you saying that schedule_work() won't work? It will quite likely be very
> lossy, but why won't it work at all?
> 
> How would that softirq approach work? Could you point me to some reference
> code?

Look at the tasklet stuff I guess. Look at tasklet_hi_schedule() and co.