Received: by 10.192.165.148 with SMTP id m20csp1474758imm; Wed, 2 May 2018 23:17:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZruECBoByzEUoSeNuCRuk4JUqPuB2F6HAbg32noPQVGu2E0fXPa9bupE+dC7fnNAy497j2b X-Received: by 2002:a65:6250:: with SMTP id q16-v6mr2764903pgv.113.1525328253593; Wed, 02 May 2018 23:17:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525328253; cv=none; d=google.com; s=arc-20160816; b=jF022cyu4XPgoNDFCUBU/M99slQZWrfmwxJLYIDzg4jqOr5TikDztH2VW7/+bDDYJ/ BR8Jzg2gs3JcqTtL5gHq/h0Wcx+McC1ZMz2CCIr5qSDgc8pSTzdHolqeClV5835lvJF7 yuupmNrbEU4wtyfbOThgzOiCfKJe/lKdASTnl5PbPlD3OfEzb6Rg3KpdvFNLGPiIVp5R svmsJ70FzpL1gkHkQuv7QtukIwwVS0gFtDbfp1UylP/ifXU6pzf3755qXliLC91Ay0Zi K1v8J5sglz12E6Dw4h/I0puCEX1PFxc9MyGL7ts5a1eDCvvNXGnsqQP5RPqqNxcZAEbD 3f0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=Pk9gXir4m/2gxokvTUwxNwbAO569ZznX2en059VC2ks=; b=N4J54wls9dLqmOzJSkh4Lnn6KJkKaYEPOmUkoiDGILO2FH5smY6iYK0Oh2ig81uIu0 GECIJyX00lqcBDiUv4URIZ5A/G7IiqLRdwWoSC2FCfPEuQ0G/dNl0ZPLYAw7aJEHxPNV J+65DHJ78+dQXyZtOCR9W7oqIvDmt1/QXAe2zsvK2CF+zcfaPeXwyiABmPmuqtpsmtH4 BXH9TDxC0xPj+p7N4KYthe17mEPOmMfLa8A+gjNurRniJ9I3JfYMB5xxFSzDHlDQg52l H0UlxRhE9+obYciRPda4LuK4aRE0OJqftU+H/2rDtYzyCyXeKLnqigYEN2q78vCGMNPu GqvQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y63si13620812pfg.121.2018.05.02.23.17.19; Wed, 02 May 2018 23:17:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751993AbeECGRH (ORCPT + 99 others); Thu, 3 May 2018 02:17:07 -0400 Received: from mga05.intel.com ([192.55.52.43]:59498 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750923AbeECGRG (ORCPT ); Thu, 3 May 2018 02:17:06 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2018 23:17:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,356,1520924400"; d="scan'208";a="36495440" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.168]) ([10.237.72.168]) by fmsmga007.fm.intel.com with ESMTP; 02 May 2018 23:17:03 -0700 Subject: Re: [RFC] perf record: dead code perf_event__synthesize_id_index() To: Jiri Olsa , Stephane Eranian Cc: LKML , Arnaldo Carvalho de Melo , mingo@elte.hu, Peter Zijlstra , "Shishkin, Alexander" References: <20180502165737.GF11539@krava> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: Date: Thu, 3 May 2018 09:15:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180502165737.GF11539@krava> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/05/18 19:57, Jiri Olsa wrote: > On Wed, May 02, 2018 at 04:38:33PM +0000, Stephane Eranian wrote: >> Hi, >> >> It looks like perf_event__synthesize_id_index() is dead code in the current >> tip >> tree. I don't see any invocation of the function anywhere in perf.I >> understand why >> you'd want to keep the rest of the code related to PERF_RECORD_ID_INDEX >> because some perf.data file may have this user-level record type. But the >> synthesize code is not needed anymore, in my opinion. >> >> Shouldn't we remove this code? > > looks like there never was any user of it, probably some > preparation for follow up that haven't happened yet.. Adrian? Yes it is for AUX area sampling support, which we have patches for. Just waiting on Alex to get the kernel side accepted.