Re: contention on profile_lock

[Jesse Barnes <jbarnes@engr.sgi.com>]

On Tuesday, November 2, 2004 12:02 pm, Jack Steiner wrote:
> On Tue, Nov 02, 2004 at 11:52:15AM -0800, Jesse Barnes wrote:
> > Hmm, the last patch you sent me worked ok, so I'm not sure why we're
> > seeing problems with profiling now.  There seems to be very heavy
> > contention on profile_lock since profile_hook is called unconditionally
> > every timer tick. Should it only be called if profiling is enabled?  Is
> > there a way we can check the notifier list to see if it's empty before
> > calling it or something? The only user appears to be oprofile timer based
> > profiling, so in the general case we're taking the profile_lock and not
> > doing anything.
> >
> > Thanks,
> > Jesse
>
> Calling profile_hook() only if the notifier list is non-empty seems like a
> good step but I don't think that is the complete fix. We need to be able to
> enable profiling without killing performance.

Agreed.  Dipankar already suggested RCUifying the notifier list, but another 
option would be to simply check to see if oprofile timer based profiling is 
enabled since it seems to be the only user.  That would turn a lock into a 
read-mostly variable at least.

Jesse