Re: commit b00bc0b237055b breaking perf subsystem

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 19 Nov 2009, Arjan van de Ven wrote:
> commit b00bc0b237055b4c45816325ee14f0bd83e6f590
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date:   Mon Nov 2 13:01:56 2009 +0100
> 
>     uids: Prevent tear down race
> 
> has been bisected to break the perf system between -rc5 and -rc7;
> and reverting this patch in rc7 also fixes the issue.

Sigh, today seems to be the day of bisect madness.

I'm not buying direct related perf breakage from fixing that race.

Yes, I'm paranoid, but:
     Does your config have CONFIG_USER_SCHED=y ?

> now this patch is.... fun and seemingly unrelated to perf, so I
> am pretty sure something else is going on.

I fully agree, but ...
 
> the symptom of the breakage is that a userland client of perf
> (in my case, powertop) does not get to see new events if there
> is only, say, one or two of them. The data_head pointer just does
> not get updated.
> 
> Based on the patch, I have a suspicion that this pointer gets updated
> from synchronize RCU context, and this patch just makes that happen
> more.

... I have no idea how you associate that patch with the data_head
pointer and why this patch increases the sync RCU update frequency.

> If that is the case, what we really need is a new ioctl to perf that
> will cause all pending buffer state to be flushed to the ring buffer,
> that applications using perf can then just always call before looking
> at the ring. As a concept, that sounds like a good idea to me anyway...
> 
> comments/suggestions/saying-I'm-full-of-sh*t ?

I fear the latter unless you come up with some coherent explanation of
connecting that patch to rcu and the data_head pointer.

Thanks,

	tglx