From: Jesse Barnes <jbarnes@engr.sgi.com>
To: Jack Steiner <steiner@sgi.com>
Subject: Re: contention on profile_lock
Date: Tue, 2 Nov 2004 13:42:36 -0800
User-Agent: KMail/1.7
Cc: wli@holomorphy.com, linux-kernel@vger.kernel.org, edwardsg@sgi.com
References: <200411021152.16038.jbarnes@engr.sgi.com> <20041102200222.GA5135@sgi.com>
In-Reply-To: <20041102200222.GA5135@sgi.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200411021342.36918.jbarnes@engr.sgi.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1412
Lines: 29

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/