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 310F1C433EF for ; Sat, 12 Feb 2022 04:21:38 +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=mTjpUvxAGjkQXeeAlsYGNM7iImxla6SNwPpgYDNRZX8=; b=Jzx5/nR2T8GmDH KtWY/+sYmwsoj7VrM9LQANJhpXLeZdquktVNfvVJQAOQ5oIAJBfeHn+s5Cae++EX8EgUqEWMK+aAf o8n4SoHVdQSAk/+bSz8fLWjwisdY8JfdTltzdMIF5lc+KN0i0Ye8U+64RcZtaXKfEmi3wuKX44p/k mv6x/rFgWVCpBOFfLV20jWnym2y2tHnIXiAk9W5m3S4LaUZ9B5BLyxk/vpMUw9/PrCN+lCpyPoV8p b1CHmso8QHLt5Ebhvjb/l6rnsiPOIwgZihNh3sKTXuwHKn0tDfnY0v5EWsTareTezixfd+q0DzBKF ALvzBxRJC0k2aBboBGPQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nIjsp-009O0K-Sc; Sat, 12 Feb 2022 04:19:40 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nIjsm-009NzR-Br for linux-arm-kernel@lists.infradead.org; Sat, 12 Feb 2022 04:19:37 +0000 Received: by mail-ej1-x635.google.com with SMTP id h8so71143ejy.4 for ; Fri, 11 Feb 2022 20:19:35 -0800 (PST) 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:content-transfer-encoding:in-reply-to; bh=p7X05HIHlgua5QT03cwmvP2qXsowDMd5jVQ2Nq7kxys=; b=Wpijvd421OFBuVYF431Fmi7Ze13lqR9HCjLI+tGr6Que+4+k5eetxRxPIK8MUAgyQk Q2BXg6TGtESf3m5lBpDEqfcpxCdCa1KT94JGG+JlieZVx+6nU5crjs2blpzWSXK7xn0I JFqIhoKBO/d6gU7Lln9zNEzZqZ883++rtE7hTMJjU5Jfsq2fPivNKrlyOZ6stAgGa8MX yn+IqnZoX7PngInCmcd8I+NC24Rwg5zV5EKrRr0LNINqkfphnGH2qqIy7gcHjSkYhUtg UcTUCZ8Ft4rNvjK4nuFCPuR9Pesb4hc8mKDsYEvN+78t/435oULr9rZ4ara0Hmq1/qJ/ 1sfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=p7X05HIHlgua5QT03cwmvP2qXsowDMd5jVQ2Nq7kxys=; b=H63o32qZVQhAoNbFg6aJK8I/4fQ4hXh/ZbBzWNwnYCx16N9U9kj9oje5ZxZ6cDxul+ Tl3krjwRw5ayrF3EXNQm9nWZTPfSmb2kEoALGbAVDRxxZIGxLC0L8+IPH1leu5MV/1jY P2BU/OgSsOace2DMbTAEg2Y0jQ7VjvwC9YE61INBy65LnltbeHOX38648sVYjTpj6FVz 7KGk41+DdwXRlMlBcv/MTZwAUczRmQUuK2NIDCPdRsy4xzlamhaw3QuDlJtTVp2tB9FB I2ITEV65HYGM97Fu0xdK+H3suGAGELiRjCs/UZtGTZ4/axUB+80JBQ12f3SV8gnu5sKf Ju4w== X-Gm-Message-State: AOAM532zHQGpm9zE2A3dZkvq+uSQHgaK4dedRcE6+gmc1ADgsofAMfTG jBbwC8N65agJI4aFJoMqS578Vw== X-Google-Smtp-Source: ABdhPJyMYSrRWUtGrCZyMqVLTyz2rtvX46h43uMrcgvkEOKz+ARG+74NeG39H938HbzX63ZBtYJI+g== X-Received: by 2002:a17:907:868d:: with SMTP id qa13mr3740651ejc.508.1644639574621; Fri, 11 Feb 2022 20:19:34 -0800 (PST) Received: from leoy-ThinkPad-X240s ([104.245.96.223]) by smtp.gmail.com with ESMTPSA id eg11sm10340818edb.17.2022.02.11.20.19.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Feb 2022 20:19:33 -0800 (PST) Date: Sat, 12 Feb 2022 12:19:27 +0800 From: Leo Yan To: German Gomez Cc: Ali Saidi , acme@kernel.org, alexander.shishkin@linux.intel.com, andrew.kilroy@arm.com, benh@kernel.crashing.org, james.clark@arm.com, john.garry@huawei.com, jolsa@redhat.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, mark.rutland@arm.com, mathieu.poirier@linaro.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, will@kernel.org Subject: Re: [PATCH 2/2] perf arm-spe: Parse more SPE fields and store source Message-ID: <20220212041927.GA763461@leoy-ThinkPad-X240s> References: <20220128210245.4628-1-alisaidi@amazon.com> <7eca7a1d-a5a2-2aab-b3cf-5d83cb8ccf4f@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7eca7a1d-a5a2-2aab-b3cf-5d83cb8ccf4f@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220211_201936_440159_225085BE X-CRM114-Status: GOOD ( 17.04 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi German, Ali, On Fri, Feb 11, 2022 at 04:31:40PM +0000, German Gomez wrote: > Hi Ali, > = > On 28/01/2022 21:02, Ali Saidi wrote: > > Hi German, > > > > On 28/01/2022 19:20, German Gomez wrote: > >> Hi Ali, > >> > >> [...] > >>> }; > >>> = > >>> enum arm_spe_op_type { > >>> ARM_SPE_LD =3D 1 << 0, > >>> ARM_SPE_ST =3D 1 << 1, > >>> + ARM_SPE_LDST_EXCL =3D 1 << 2, > >>> + ARM_SPE_LDST_ATOMIC =3D 1 << 3, > >>> + ARM_SPE_LDST_ACQREL =3D 1 << 4, > = > Wondering if we can store this in perf_sample->flags. The values are > defined in "util/event.h" (PERF_IP_*). Maybe we can extend it to allow > doing "sample->flags =3D PERF_LDST_FLAG_LD | PERF_LDST_FLAG_ATOMIC" and > such. > = > @Leo do you think that could work? Let's step back a bit and divide the decoding flow into two parts: backend and frontend. For the backend part, we decode the SPE hardware trace data and generate the SPE record in the file util/arm-spe-decoder/arm-spe-decoder.c. As we want to support complete operation types, we can extend arm_spe_op_type as below: enum arm_spe_op_type { /* First level operation type */ ARM_SPE_OP_OTHER =3D 1 << 0, ARM_SPE_OP_LDST =3D 1 << 1, ARM_SPE_OP_BRANCH_ERET =3D 1 << 2, /* Second level operation type for OTHER */ ARM_SPE_OP_SVE_OTHER =3D 1 << 16, ARM_SPE_OP_SVE_FP =3D 1 << 17, ARM_SPE_OP_SVE_PRED =3D 1 << 18, /* Second level operation type for LDST */ ARM_SPE_OP_LD =3D 1 << 16, ARM_SPE_OP_ST =3D 1 << 17, ARM_SPE_OP_ATOMIC =3D 1 << 18, ARM_SPE_OP_EXCL =3D 1 << 19, ARM_SPE_OP_AR =3D 1 << 20, ARM_SPE_OP_SIMD_FP =3D 1 << 21, ARM_SPE_OP_GP_REG =3D 1 << 22, ARM_SPE_OP_UNSPEC_REG =3D 1 << 23, ARM_SPE_OP_NV_SYSREG =3D 1 << 24, ARM_SPE_OP_SVE_PRED =3D 1 << 25, ARM_SPE_OP_SVE_SG =3D 1 << 26, /* Second level operation type for BRANCH_ERET */ ARM_SPE_OP_BR_COND =3D 1 << 16, ARM_SPE_OP_BR_INDIRECT =3D 1 << 17, }; IIUC, Ali suggested to directly reuse packet format to express operation type and don't need to redefine the operation types like above structure arm_spe_op_type. I personally bias to convert the raw packet format to more readable format, a benefit is this would give us more readable code. For the frontend, we need to convert Arm SPE record to samples. We can explore two fields: sample::flags and sample::data_src, for load/store related operations, I perfer we can fill more complete info in field sample::data_src and extend the definitions for perf_mem_data_src; for branch operations, we can fill sample::flags. So I am just wandering if we can set the field sample::data_src::mem_lock for atomic operations, like: data_src.mem_op =3D PERF_MEM_OP_LOAD; data_src.mem_lock =3D PERF_MEM_LOCK_ATOMIC; The field "mem_lock" is only two bits, we can consider to extend the structure with an extra filed "mem_lock_ext" if it cannot meet our requirement. > >>> + ARM_SPE_BR =3D 1 << 5, > >>> + ARM_SPE_BR_COND =3D 1 << 6, > >>> + ARM_SPE_BR_IND =3D 1 << 7, > = > Seems like we can store BR_COND in the existing "branch-miss" event > (--itrace=3Db) with: > = > =A0 sample->flags =3D PERF_IP_FLAG_BRANCH; > =A0 sample->flags |=3D PERF_IP_FLAG_CONDITIONAL; > and/or > =A0 sample->flags |=3D PERF_IP_FLAG_INDIRECT; > = > PERF_IP_FLAG_INDIRECT doesn't exist yet but we can probably add it. Yes, for branch samples, this makes sense for me. Thanks, Leo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel