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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8197ACA0EC7 for ; Tue, 12 Sep 2023 01:52:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EYrxHIBIgL8YssEW35Ay6MQKoTAa63hdNueBHzhHWDs=; b=xLxz3J48t+R/uS 4y4/maRrJ40NUpTTI63+fEolkrnuaNZP05/wUzP4tb32hprojMhp1kC/3neskCTZoLtWY8lXjALKS Iey8cdHbLopfym0PJhmDsod9SYwQFJUIC+wuqOKnvFJniDLMPe/lD0IDXoZxFzo3dA111IYTBe/y6 hPtYfS1k/paZk5PQgBUPu1ZuAE2zhtKLB1DjwbUhpr2B2atINyaqHGMPCzAkmq14jTkj8Qnq65FdI SqmvmQ2W295j5Gjid7l2I2gCllUikKJtM6YtMha/q31TY/zyQnYxp8QS4qbUfG8VxwBqKbUoyPUoV k32FJ1LDY8FCWW6qxYtA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qfsZi-001lSd-1J; Tue, 12 Sep 2023 01:52:22 +0000 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qfsZf-001lPf-1D for linux-arm-kernel@lists.infradead.org; Tue, 12 Sep 2023 01:52:20 +0000 Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-68fb7fb537dso1685837b3a.2 for ; Mon, 11 Sep 2023 18:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1694483537; x=1695088337; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=kwpiguO0UbnqrBVAgkTOyqOA0TbUDGD6mC+sN7KskI0=; b=IcqH5eCHVyzxuoLcRPsEWzBEBLOFJ1q7SabQc+z3YWSHExIN+PZvaaVlIOTrDeORNE YUuUyRfwWcNS9QCh3RCL8Nr1pZ/bSSmZdsPDJI9lqMdAx6b+buNjXSJwfDVWkq4vgQFG 8DTTJETwFZDf3Dp5sqF5UHQ636Nlj/T94KRZ7t/m5yg5/YmNrHk0DzO5C6DLGaZYoYXK NyGMFufYPZZqrChc+pttXI4IHHWgmfBXkC7mG+oGmTu91WlHfeIwEkJp+1cCOmfqcy+K +MmvvGBubPFPqxlLUhK1a09r+psxplROHucUnoNEGBy/CRUdEew5W1jaWF8AGjEVJlI0 +ZvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694483537; x=1695088337; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kwpiguO0UbnqrBVAgkTOyqOA0TbUDGD6mC+sN7KskI0=; b=UjYsa6gMMuhWKHBrU6iosHGW16FRhxZjgVk0nz+qeAs6l+2+cap+N8oI9ieBcxHQZS zWQFCX2onGYWRdwiorlUH5/RQCYRwC8UFtwbGtbFlTvdkXTF7sTTacP2yrwq5Wlk1tT9 mHvVGTAxWkqDVEv1NfV0kY+Sy+rWO4esogc1e8GiccvyHvmSJ2YFevjk89v0q0kdnc2N PcNOb4GdS0XlHoUbOk/PigUhpjqEy6yhqVEDARibApXj3Yybb91+AwLjOHv7Pjdlqd/M K7dJeQ5IcoBbt3ujcfINrLv6KjkzciWRM1/QeH4K/Yq4Y+L9aUrUuhOwiZVS2iNdBKGy 664g== X-Gm-Message-State: AOJu0Yz1N5ONJHH5ppOlKO7EkxyDT/GtlTHP9qb5cHMTEFZeKNGpCYF1 7u/CNs4nBiyj0xhJX+XfeT75NA== X-Google-Smtp-Source: AGHT+IF/LWkrzxBsF4AhQ5qgJsif8/E6lwiCAOPaiSUpQOXYS8By3op3abZdkkmIE99m2dH1kStZ6Q== X-Received: by 2002:a05:6a21:47ca:b0:14b:f365:288a with SMTP id as10-20020a056a2147ca00b0014bf365288amr7505296pzc.47.1694483536714; Mon, 11 Sep 2023 18:52:16 -0700 (PDT) Received: from leoy-huanghe ([98.98.49.243]) by smtp.gmail.com with ESMTPSA id on10-20020a17090b1d0a00b0026b76edd607sm6414392pjb.15.2023.09.11.18.52.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Sep 2023 18:52:16 -0700 (PDT) Date: Tue, 12 Sep 2023 09:52:04 +0800 From: Leo Yan To: James Clark Cc: Arnaldo Carvalho de Melo , Suzuki K Poulose , Mike Leach , John Garry , Will Deacon , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] perf cs-etm: Fix kernel timestamp handling Message-ID: <20230912015204.GA122656@leoy-huanghe> References: <20230910092413.53538-1-leo.yan@linaro.org> <04823db9-ed6c-0695-b9de-5a63bfa0aa5a@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <04823db9-ed6c-0695-b9de-5a63bfa0aa5a@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230911_185219_516773_5C242BBA X-CRM114-Status: GOOD ( 38.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi James, On Mon, Sep 11, 2023 at 02:24:09PM +0100, James Clark wrote: [...] > > The current code can support both timestamp sources when synthesizing > > samples. However, the decoding flow only relies on the hardware > > timestamp. If the hardware timestamp is zero, it becomes impossible to > > decode the trace data. Consequently, in this case, the commands below > > won't output any samples: > > > > perf record -e cs_etm// --per-thread --timestamp -- ls > > perf script > > Hi Leo, > > I couldn't reproduce this issue, even when hard coding the hardware > timestamp to zero in cs_etm_decoder__do_hard_timestamp() like this: > > converted_timestamp = 0; I reproduced this issue on the Juno-r2 board, its "etm->has_virtual_ts" is always false and Arm CoreSight timestamp packets are zeros. Besides set "converted_timestamp = 0", it might need to hard code "etm->has_virtual_ts" to false? > I'm not sure why this would result in no samples being generated either, > because we don't actually use the timestamps for anything yet [1]. We > always wait until the very end of the file before decoding to ensure > that all of the mmaps are loaded. And the timestamp is just assigned to > the samples, but they shouldn't affect whether they are generated or not. > > Unless there is something else I'm missing? Let's review below code. cs_etm__queue_first_cs_timestamp() retrieves trace data and decodes it, and breaks the while loop until it find the timestamp is not zero or no trace data is avaliable. When the timestamp is always zero, the while loop continues to drop the CoreSight trace data and don't synthesize samples. cs_etm__queue_first_cs_timestamp() { ... while(1) { ret = cs_etm__get_data_block(etmq); if (ret <= 0) goto out; ret = cs_etm__decode_data_block(etmq); if (ret) goto out; cs_timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id); /* We found a timestamp, no need to continue. */ if (cs_timestamp) break; cs_etm__clear_all_packet_queues(etmq); } } > Also, in cs_etm__queue_first_cs_timestamp(), cs_timestamp is used for > sorting the decoding order between CPUs, but if the hardware timestamp > is 0, then it's 0 on all trace. Correct. > So the sorting would be the same if you change that to be the kernel > timestamp. They're all still the same > static number, but just a different number (because we wait until the > end of the file, 'latest_kernel_timestamp' is always the timestamp of > the last AUX event in the file). If we use the 'latest_kernel_timestamp' as timestamp, it's non-zero timestamp rather than all timestamp '0'. Yes, 'latest_kernel_timestamp' is a coarse kernel timestamp which is shared by all trace data recorded in the AUX event, though it's a static number, it can allow us to break the while loop mentioned above. I understand 'latest_kernel_timestamp' is inaccurate for sorting, but as least now it exists in current code, quotes from util/cs-etm.c: /* * Record the latest kernel timestamp available in the header * for samples so that synthesised samples occur from this point * onwards. */ if (sample->time && (sample->time != (u64)-1)) etm->latest_kernel_timestamp = sample->time; > [1]: I still plan to change the decoding to decode up to the current > time in the file, rather than waiting for the end of the file before > starting. That way decoding trace when there were overlapping mmap > regions in time will be more accurate. Thanks for heading up. I am not sure if I understand this correctly, but seems to me it is a good thing to try for using overlapping mmap events. Just a side topic, if an Arm platform connect the Arm timer counter to Arm CoreSight, and detect virtual timestamp is false (thus etm->has_virtual_ts is 0). I think this might happen on some legacy platforms, can we use some ways to allow users to still use the Arm CoreSight timestamp in this case? E.g. we can force set etm->has_virtual_ts to 1 when user specify the config '-e cs_etm/timestamp/'. Thanks, Leo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel