Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755880Ab3JHT5u (ORCPT ); Tue, 8 Oct 2013 15:57:50 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:43993 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751751Ab3JHT5s (ORCPT ); Tue, 8 Oct 2013 15:57:48 -0400 Message-ID: <525463B7.3030203@gmail.com> Date: Tue, 08 Oct 2013 13:57:43 -0600 From: David Ahern User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephane Eranian CC: Ingo Molnar , LKML , Peter Zijlstra , "mingo@elte.hu" , "ak@linux.intel.com" , Arnaldo Carvalho de Melo , Jiri Olsa , Hugh Dickins Subject: Re: [RFC] perf: mmap2 not covering VM_CLONE regions References: <52541556.5060907@gmail.com> <20131008194129.GC7315@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1353 Lines: 30 On 10/8/13 1:54 PM, Stephane Eranian wrote: >>> If the current MMAP2 is not a complete solution for what you (Google) >>> need, should support be reverted before 3.12 is released? No sense in >>> making this part of the forever API if more work is needed on it. >> >> Instead of a full revert we could just turn off the ABI portion minimally >> and not recognize it for now. Assuming a more complete solution is in the >> works for v3.13. >> > That's a possibility. They are also pieces in the perf tool itself. > We could certainly make the attr->mmap2 bit disappear. > > I think it boils down to how can we uniquely identify virtual > mapping to the same physical data either via shmat(), files, VM_CLONE. > We had all covered but the last case with the ino approach. We don't have > a solution for VM_CLONE yet. > I was mainly thinking the 2 parts that generate MMAP2 events: kernel side it's the mmap2 attribute and perf_event_mmap_output; userspace side it's perf_event__synthesize_mmap_event. Certainly the rest of the plumbing can be left in place until the solution is refined as needed. David -- 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/