From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932665AbbJIHCq (ORCPT ); Fri, 9 Oct 2015 03:02:46 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:35051 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752429AbbJIHCp (ORCPT ); Fri, 9 Oct 2015 03:02:45 -0400 Date: Fri, 9 Oct 2015 15:58:49 +0900 From: Namhyung Kim To: Jiri Olsa Cc: Arnaldo Carvalho de Melo , Ingo Molnar , Peter Zijlstra , LKML , Frederic Weisbecker , Stephane Eranian , David Ahern , Andi Kleen Subject: Re: [RFC/PATCH 17/38] perf tools: Maintain map groups list in a leader thread Message-ID: <20151009065849.GA5561@danjae.orange-hotspot.com> References: <1443763159-29098-1-git-send-email-namhyung@kernel.org> <1443763159-29098-18-git-send-email-namhyung@kernel.org> <20151008125800.GC14829@krava.landal.opennet> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151008125800.GC14829@krava.landal.opennet> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 08, 2015 at 02:58:00PM +0200, Jiri Olsa wrote: > On Fri, Oct 02, 2015 at 02:18:58PM +0900, Namhyung Kim wrote: > > SNIP > > > int __thread__set_comm(struct thread *thread, const char *str, u64 timestamp, > > bool exec) > > { > > @@ -182,6 +257,40 @@ int __thread__set_comm(struct thread *thread, const char *str, u64 timestamp, > > unwind__flush_access(thread); > > } > > > > + if (exec) { > > + struct machine *machine; > > + > > + BUG_ON(thread->mg == NULL || thread->mg->machine == NULL); > > + > > + machine = thread->mg->machine; > > + > > + if (thread->tid != thread->pid_) { > > + struct map_groups *old = thread->mg; > > + struct thread *leader; > > + > > + leader = machine__findnew_thread(machine, thread->pid_, > > + thread->pid_); > > + > > + /* now it'll be a new leader */ > > + thread->pid_ = thread->tid; > > + > > + thread->mg = map_groups__new(old->machine); > > + if (thread->mg == NULL) > > + return -ENOMEM; > > + > > + /* save current mg in the new leader */ > > + thread__clone_map_groups(thread, leader); > > + > > + /* current mg of leader thread needs one more refcnt */ > > + map_groups__get(thread->mg); > > + > > + thread__set_map_groups(thread, thread->mg, old->timestamp); > > + } > > + > > + /* create a new mg for newly executed binary */ > > + thread__set_map_groups(thread, map_groups__new(machine), timestamp); > > should this ^^^^ be in the else case of above condition? Nop. Above condition is to make the thread a new leader thread and for that purpose, it clones old thread->mg and add into the mg_list. Because a non-leader thread don't have mg_list. After that, we can add a new mg to the now-available mg_list. > > also thread__fork calls thread__clone_map_groups once again, > I have some difficulty to sort this out ATM.. is that correct? In fork case, above code will not be called since it's only for exec path. > > some comment on how we treat map groups in general (for fork/clone/exit) > would be awesome ;-) I admit that this code is subtle and confusing.. How about this? Managing map groups is subtle in that we basically want to share a map groups between threads in a process. When a new process is created (forked), the child clones (current) map groups from the parent. But if a new thread is called it only gets a reference of the leader's mg. Complication comes from the exec as we also want to keep the history of a thread's execution, so the map groups are now managed by mg_list. This mg_list is maintained by leader threads only, and non-leader threads have a reference a mg at the time in the mg_list. It uses a timestamp at the event to find out the correct mg in the mg_list. One corner case is when exec is called from a non-leader thread. We want to add a new mg to the mg_list in the thread. But it doesn't have a mg_list since it was not a leader. So it sets up a mg_list and insert a cloned mg from the old leader. Now it can handle exec as usual - create a new mg and insert it to the mg_list. Thanks, Namhyung