From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753162AbbC3NHH (ORCPT ); Mon, 30 Mar 2015 09:07:07 -0400 Received: from casper.infradead.org ([85.118.1.10]:33075 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752936AbbC3NHC (ORCPT ); Mon, 30 Mar 2015 09:07:02 -0400 Date: Mon, 30 Mar 2015 10:07:08 -0300 From: Arnaldo Carvalho de Melo To: Jiri Olsa Cc: Namhyung Kim , David Ahern , Jiri Olsa , Stephane Eranian , LKML Subject: Re: [BUG] segfault in perf-top -- thread refcnt Message-ID: <20150330130708.GA24063@kernel.org> References: <551593EA.2030201@gmail.com> <20150327201126.GM21510@kernel.org> <5515B9E6.5020007@gmail.com> <20150330080737.GD1413@krava> <20150330102220.GE1413@krava> <20150330112108.GG1413@krava> <20150330114907.GH1413@krava> <20150330124852.GA4507@danjae.kornet> <20150330125631.GI1413@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330125631.GI1413@krava> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Mon, Mar 30, 2015 at 02:56:31PM +0200, Jiri Olsa escreveu: > On Mon, Mar 30, 2015 at 09:48:52PM +0900, Namhyung Kim wrote: > > Hi Jiri, > > > > On Mon, Mar 30, 2015 at 01:49:07PM +0200, Jiri Olsa wrote: > > > On Mon, Mar 30, 2015 at 01:21:08PM +0200, Jiri Olsa wrote: > > > > On Mon, Mar 30, 2015 at 12:22:20PM +0200, Jiri Olsa wrote: > > > > > On Mon, Mar 30, 2015 at 10:07:37AM +0200, Jiri Olsa wrote: > > > - th = thread__new(pid, tid); > > > + th = thread__new(machine, pid, tid); > > > if (th != NULL) { > > > + > > > + pthread_mutex_lock(&machine->threads_lock); > > > rb_link_node(&th->rb_node, parent, p); > > > rb_insert_color(&th->rb_node, &machine->threads); > > > + pthread_mutex_unlock(&machine->threads_lock); > > > > I think you also need to protect the rb tree traversal above. > > yep, I already have another version.. but it blows on another place ;-) Well, why? The point of refcounting is that the structure will not go away while we have it in the rbtree. Or are you talking about two threads trying to insert entries in the rbtree? Can you point where this can happen? > > But this makes every sample processing grabs and releases the lock so > > might cause high overhead. It can be a problem if such processing is > > done parallelly like my multi-thread work. :-/ > yep.. perhaps instead of more locking we need to find a way where > only single thread do the update on hists/threads But that should be really rare, no? The problem is to search in one thread (the fast path) and inserting entries (slow path), no? - Arnaldo