From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5C86C433B4 for ; Tue, 11 May 2021 01:15:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7A9AD61624 for ; Tue, 11 May 2021 01:15:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230070AbhEKBQi (ORCPT ); Mon, 10 May 2021 21:16:38 -0400 Received: from mga04.intel.com ([192.55.52.120]:8317 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229920AbhEKBQg (ORCPT ); Mon, 10 May 2021 21:16:36 -0400 IronPort-SDR: ZxmTUo5/SdwjWQVzsUhN5M6ow+HFzDQU5bgzHYTHTNiSKefhzWMJyRUHcJr2xt73BJXBUKg3qP oPtDt+Hwiszg== X-IronPort-AV: E=McAfee;i="6200,9189,9980"; a="197343482" X-IronPort-AV: E=Sophos;i="5.82,290,1613462400"; d="scan'208";a="197343482" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2021 18:15:31 -0700 IronPort-SDR: rLv7jY/3kBuzYMTV3rx0id8R76ZofJs8fvOdYemXecoT5NHN0gChnNr9eiQiiL5ILvDVWdBjjK POTa+QcP0bdA== X-IronPort-AV: E=Sophos;i="5.82,290,1613462400"; d="scan'208";a="436397817" Received: from yjin15-mobl1.ccr.corp.intel.com (HELO [10.238.4.82]) ([10.238.4.82]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2021 18:15:28 -0700 Subject: Re: [PATCH v1 2/2] perf header: Support hybrid CPU_PMU_CAPS To: Jiri Olsa Cc: acme@kernel.org, jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org, ak@linux.intel.com, kan.liang@intel.com, yao.jin@intel.com References: <20210430074602.3028-1-yao.jin@linux.intel.com> <20210430074602.3028-2-yao.jin@linux.intel.com> <5cafb729-1dcd-ad4a-507b-1155c16a785e@linux.intel.com> From: "Jin, Yao" Message-ID: <249153c0-a560-aa78-97a9-039dee5be86b@linux.intel.com> Date: Tue, 11 May 2021 09:15:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jiri, On 5/10/2021 9:11 PM, Jiri Olsa wrote: > On Thu, May 06, 2021 at 10:43:39PM +0800, Jin, Yao wrote: > > SNIP > >>>> 'nr of rest pmus', we know that all pmus have been processed. >>>> >>>> Otherwise, we have to continue reading data file till we find something >>>> incorrect and then finally drop the last read data. >>> >>> you have the size of the feature data right? I think we use >>> it in other cases to check if there are more data >>> >> >> The challenge for us is if we need to compatible with the old perf.data >> which was generated by old perf tool. >> >> For the old perf.data, the layout in header is: >> >> nr of caps >> caps string 1 >> caps string 2 >> ... >> caps string N >> >> It doesn't carry with any other fields such as size of caps data. >> >> To be compatible with old perf.data, so I have to extend the layout to: >> >> nr of caps for pmu 1 >> caps string 1 >> caps string 2 >> ... >> caps string N >> name of pmu 1 >> nr of rest pmus >> >> nr of caps for pmu2 >> caps string 1 >> caps string 2 >> ... >> caps string N >> name of pmu 2 >> nr of rest pmus >> >> When the new perf tool detects the string such as "cpu_", it can know that >> it's the pmu name field in new perf.data, otherwise it's the old perf.data. > > what if the cap string starts with 'cpu_' ? > I just assume the cap string would not have 'cpu_' string. Yes, I agree, that's not a very good solution. > I think it might be better to create new feature that > stores caps for multiple pmus in generic way > Yes, creating a new feature in header (such as "HYBRID_CPU_PMU_CAPS") is a better way. >> >> If we add new field such as "size" to the layout, I'm afraid the new perf >> tool can not process the old perf.data correctly. >> >> If we don't need to support old perf.data, that makes things easy. > > we need to > Yes, we need to. I'm now preparing v3. Thanks Jin Yao > jirka >