Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp415421pxb; Fri, 16 Apr 2021 08:41:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxEMsaseUkIMraqF8XF8wMq4U/mmimTQGY80qdvesxPUKF09OHH694bYlKzWmHu8RO0S0Da X-Received: by 2002:a17:902:bd09:b029:ec:7e58:a54a with SMTP id p9-20020a170902bd09b02900ec7e58a54amr2693698pls.62.1618587713834; Fri, 16 Apr 2021 08:41:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618587713; cv=none; d=google.com; s=arc-20160816; b=PqUE5eE2pxA8Z5aygsKZg6k0GJ+H4FGqrCZfBkGcgRerXQTkOopUi76neV8Jv1zv+5 L01FYb5RAl2/DJvulF374BM/JkGgMdGycgam57pL78J6sj5H4N/iNBHv7gcE/t984kUM rdlNZ3H/eNXiJaxXgmo2GX3cl0LnbF4QcOfFVg/ORNUWGXtOgoTDGheDGRB7+H5QABt9 kaWWjF/LFOw8Pl45Hr6Sd+BIXLjj+V+po3Zzb6e+sEHGeMBl8E/BoRAsDi+X00+ACwaB hpj/s4ZfgO8PHoJygEr+Lbbg8CDiP2Wn1NBcqIjmCWORuMWpnMj0DYpPDttqEIjjEkQc qNFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=jNEOUMLacDExesI1dUec+Ag9poKcQi7/Bd0G3kzBs+E=; b=Jf/+MCcgfO5q/HVbtbzOlMCvmDVh+jmWIZB1v2AuwAGiV6Yw71D0e3UtRMXsfux5Vw MPn90AdLV4mKbIwx3bsjELgAc1ScSiZTLvmNdStAeK9vQQKDdZCUN05riRG7QS5O3ON5 j0yJvy/qvu9HbzZ434rzy/iLWyDlEtmFJIS9fr9EHpDaGRnb9dKPDlATBvdN8K3lnF2A ThYVjtxG40x89awZF9Pxy6D3/wufBJBu1eQABWIMOnMHJp5+nmtmw3aP5PtxRhsVVimY RsWoEpZFZnHGWIcmkKTzrxijfhvw3hTpwZlIZFQIqB0hUVdag2IBd3Ln7BKgdCnFMz7u 3YpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="D9/9Ayax"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q4si7214718pfj.237.2021.04.16.08.41.41; Fri, 16 Apr 2021 08:41:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="D9/9Ayax"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243556AbhDPNVk (ORCPT + 99 others); Fri, 16 Apr 2021 09:21:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56376 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235361AbhDPNVj (ORCPT ); Fri, 16 Apr 2021 09:21:39 -0400 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0464AC061574 for ; Fri, 16 Apr 2021 06:21:14 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id nm3-20020a17090b19c3b029014e1bbf6c60so10418125pjb.4 for ; Fri, 16 Apr 2021 06:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jNEOUMLacDExesI1dUec+Ag9poKcQi7/Bd0G3kzBs+E=; b=D9/9AyaxROOMxeGsn1K8bCTaAQz95ClMBt4f11oG2tHr3a0M33smsXCK4q9FqRHGBh rJr717NgoXD6Xjlj0KIusADW3eOuGNlu6va6ZfniMI+gCRFsH04lKBZ3t+IYqN3AAggx JuLfL0nFO//BkVvzHzeY7uYBlFzBGZRnUuCpYIDi5d6NS77FI6UbzUYAGQyFqSQiBz+7 wHOICFkSF0jU+ggXpXJf7pgFZKIOBfsIH/TyRMLY2mQjgN89BBvsPRBaAn4Cx16OTMNP Ru+6MiBawOLCueVpyWyWqsDR5GhtvGaYZ+iKz+/uNAhWQhb1oemX8vjWp4E6VVkauGqd h3Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jNEOUMLacDExesI1dUec+Ag9poKcQi7/Bd0G3kzBs+E=; b=GY05gwG3vXxhjYKk0Sz+bvr8QVcAzcbCB1tIZjo4J/K4r+O5NLWFvshIZQUFMsSuUX AlZJT30NBvPMi67PqDVWW6KBZYHfJiTYwihO9fug87BrwrQad4C8Vviu/5re2BRhkpIs PRj1mDB7F17YydglZ0XkoZuK9347MbtooHMWKDvw5q2wMICZh8rvF9CbDbskIHiu7yfu YOPjo0LtD8omv0helSTG70zsgbDU3KPsGKr13nyC3np7MRoERZzdJ9orMZil9BKt86xf NCpQvykh9w+NDGRtAKDcgcZi5Npy4XESQhsOgS/uOziT3d1OBQAPlXstWvEQ4/xTieqH 0U7Q== X-Gm-Message-State: AOAM533cemWKTqWXSeD8c2+TLOytJ1IMVOiqJAyAkLRC5euI3ShIcZ6Z tswQXt07GUnbbc8eUIZIDbw6KQ== X-Received: by 2002:a17:90a:150e:: with SMTP id l14mr6643850pja.208.1618579273482; Fri, 16 Apr 2021 06:21:13 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([204.124.180.30]) by smtp.gmail.com with ESMTPSA id x13sm6617982pja.3.2021.04.16.06.21.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Apr 2021 06:21:12 -0700 (PDT) Date: Fri, 16 Apr 2021 21:21:04 +0800 From: Leo Yan To: James Clark Cc: Arnaldo Carvalho de Melo , Al Grant , John Garry , Will Deacon , Mathieu Poirier , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Adrian Hunter , Dave Martin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 4/6] perf arm-spe: Assign kernel time to synthesized event Message-ID: <20210416132104.GG1011890@leoy-ThinkPad-X240s> References: <20210412091006.468557-1-leo.yan@linaro.org> <20210412091006.468557-5-leo.yan@linaro.org> <9036368a-e824-3d63-da5b-54cf32a86aed@arm.com> <20210415152348.GF1011890@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 16, 2021 at 03:51:25PM +0300, James Clark wrote: [...] > >> I noticed that in arm_spe_recording_options() the TIME sample bit is set regardless of any options. > >> I don't know of a way to remove this, and if there isn't, does that mean that all the code in this > >> file that looks at spe->timeless_decoding is untested and has never been hit? > >> > >> Unless there is a way to get a perf file with only the AUXTRACE event and no others? I think that one > >> might have no timestamp set. Otherwise other events will always have timestamps so spe->timeless_decoding > >> is always false. > > > > Good point. To be honest, I never noticed this issue until you > > mentioned this. > > > > We should fix for the "timeless" flow; and it's questionable for the > > function arm_spe_recording_options(), except for setting > > PERF_SAMPLE_TIME, it also hard codes for setting > > PERF_SAMPLE_CPU and PERF_SAMPLE_TID. Might need to carefully go > > through this function. > > > > Yeah, it's not strictly related to your change, which is definitely an improvement. > But maybe we should have a look at the SPE implementation relating to timestamps as a whole. Totally agree, at least this patch series should not introduce any barrier for timeless case. I will go back to verify it; if you'd like to fix timeless issue, please feel free to go ahead. Thanks, Leo