From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752001AbbJLMnk (ORCPT ); Mon, 12 Oct 2015 08:43:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50568 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751563AbbJLMnj (ORCPT ); Mon, 12 Oct 2015 08:43:39 -0400 Date: Mon, 12 Oct 2015 14:43:36 +0200 From: Jiri Olsa To: Namhyung Kim 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: <20151012124336.GB32196@krava.brq.redhat.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> <20151009065849.GA5561@danjae.orange-hotspot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151009065849.GA5561@danjae.orange-hotspot.com> 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 Fri, Oct 09, 2015 at 03:58:49PM +0900, Namhyung Kim wrote: SNIP > > > > > > 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. seems ok, thanks jirka