lkml.org 
[lkml]   [2009]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: commit b00bc0b237055b breaking perf subsystem
From
Date
On Thu, 2009-11-19 at 11:50 -0800, 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.
>
> now this patch is.... fun and seemingly unrelated to perf, so I
> am pretty sure something else is going on.
>
> 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.
>
> 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 ?

We should be updating the data_head pointer after every writen event
(with the exception of nested writes, where we delay publishing until
the last writer is done, so as to not expose incomplete data).

perf_output_begin(); /* reserve space */
perf_output_copy(); /* write bits to space */
perf_output_end(); /* commit and publish */
perf_output_unlock();
/* complicated stuff to publish data_head */

Colour me puzzled on how this particular commit can have any effect on
data_head.



\
 
 \ /
  Last update: 2009-11-19 21:05    [W:0.066 / U:1.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site