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 D20ADC433EF for ; Thu, 25 Nov 2021 12:33:11 +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=K0LBArgPyag1L55DfL6PIqxRKjzgRu5OBcZ9HARGM+4=; b=IvnB4qLe1NPzjM G2CPONhUEor/4hI32wXnm8KOaRF1jOYd9KRAr99I5mfF+f1Au3IOety2fa7tV8STCfkfGpiKDoAIs qhHZPL8MG9bxwRHDrzbVXwrFOc6nxEanzEZjltcE5GezR8asCAWK/eYwGyQQMxASJVvhn5ZXvxY6H qmjR2tijZMEWj7AqodhhYeADKEKO+mDAtua24BR0hvTpwvh+9j+1M1mzhc9oBe9kPBZce4DCmpLOj VQxpZ/HESQMgLvY4+m+nn/cScTRh52etvkWPVnTC0MLaaMxPseuGu/6cpEht1bxNTgLolVFAVsPZ5 uycbGHl6wnZzF5UmluuA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mqDuC-007OVc-Hr; Thu, 25 Nov 2021 12:31:12 +0000 Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mqDu6-007OTj-W7 for linux-arm-kernel@lists.infradead.org; Thu, 25 Nov 2021 12:31:09 +0000 Received: by mail-pg1-x52e.google.com with SMTP id s137so5120968pgs.5 for ; Thu, 25 Nov 2021 04:31:05 -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:in-reply-to; bh=WxxRmY1avsvh6dVkHZJ0dbIbMG7eaT3D29WZ6XTQGMs=; b=JPWtHFwlPnlpUr3V/uXoLYvEvb1FSiBRFURrSZ6rQTizm+1BC+SRUOhK+I46O9QwLo M5gV5xZoZnA+4ROQZAa91s0taIZDwrMrPgi5XSDVc8BkfBFa/cLRBkj3F5tsuqY4mnT2 aVYvggaaRT4cNJfuQ1lrshfhq/COInHmAWQrpqgsQYPtbtsKXWeMj2O6SDfAywoqT4P2 wqURwsrukniCuS5RP9Hq+7Ycb9RIPUZYhIlS7AXQlk2zKfl/dgf0WUmSEK4HYuPAdMMN AT3mKc5n+wzoPzvpCewKtuNqYpGIExJD4Nu1jUahx5ThOQxWbe3RX4VbnoPFjLPNg6S8 qV+Q== 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:in-reply-to; bh=WxxRmY1avsvh6dVkHZJ0dbIbMG7eaT3D29WZ6XTQGMs=; b=j+Z2XCnY0qaunvSRGMU3IMcn6UpRs3eVWxWRvOy/wyZX73Y0cx2r492wp003b8dXtf GqXGmKBME4a2Je7DZKIK9zzqM8XiesiUmHyulpOzjdmRSjmbAfJjV6KA8XpVsBhzoABE jWSXzrUIts3cZiFcABiu7CrbXgU8ba6qFBTwzJD67oJPyR1m4o8UxqIsDmr+VQp/Spna x7ubn1oh/DNo5z8g00A7dii7bkal1e9Ssm8Es7UZOzy2wSFXPf3WePpWFtR1uRvvUcKP Qae7cGmfYpC7HxSJz9IVVC7VQfhJaP0bSj8e2xVnra/S4qcGwGhlhy2aJRxXPfQfDwim ee0Q== X-Gm-Message-State: AOAM53161kLC06Pz16zFkTx8PaefLJ1MBhfrLzIS6RKXRbcwPff+havH pHA6j7ESDrFl5DDOCHIHFaAS2g== X-Google-Smtp-Source: ABdhPJwQ4psZYW/HCtjGYY7kSbXNJVPF5eF6TJ9jiqCaiirse0B+1fNkkGePy0pzM01h5vKljnBYJg== X-Received: by 2002:a63:e04f:: with SMTP id n15mr16336706pgj.31.1637843465170; Thu, 25 Nov 2021 04:31:05 -0800 (PST) Received: from leoy-ThinkPad-X240s ([66.23.193.248]) by smtp.gmail.com with ESMTPSA id g7sm3395196pfv.159.2021.11.25.04.30.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Nov 2021 04:31:00 -0800 (PST) Date: Thu, 25 Nov 2021 20:30:53 +0800 From: Leo Yan To: James Clark Cc: German Gomez , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, acme@kernel.org, Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , John Garry , Will Deacon , Mathieu Poirier , linux-arm-kernel@lists.infradead.org Subject: Re: [RESEND PATCH 1/1] perf arm-spe: report all SPE records as "all" events Message-ID: <20211125123053.GB1599216@leoy-ThinkPad-X240s> References: <20211117142833.226629-1-german.gomez@arm.com> <20211125075358.GA1599216@leoy-ThinkPad-X240s> <12d44d96-1fcd-1fdd-64ea-beef40a27d1d@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <12d44d96-1fcd-1fdd-64ea-beef40a27d1d@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211125_043107_134117_28FFEC35 X-CRM114-Status: GOOD ( 24.16 ) 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 On Thu, Nov 25, 2021 at 10:21:48AM +0000, James Clark wrote: > On 25/11/2021 07:53, Leo Yan wrote: [...] > >> +static int arm_spe__synth_other_sample(struct arm_spe_queue *speq, > >> + u64 spe_events_id) > >> +{ > >> + struct arm_spe *spe = speq->spe; > >> + struct arm_spe_record *record = &speq->decoder->record; > >> + union perf_event *event = speq->event_buf; > >> + struct perf_sample sample = { .ip = 0, }; > >> + > >> + arm_spe_prep_sample(spe, speq, event, &sample); > >> + > >> + sample.id = spe_events_id; > >> + sample.stream_id = spe_events_id; > >> + sample.addr = record->to_ip; > > > > After checked the event types, I think "other" samples would include > > below raw event types: > > Maybe we should rename some of the functions and variables if there is > confusion, but I think this new group is "all" rather than "other" because > it also includes all the events that would be put in other groups. > > > > > EV_EXCEPTION_GEN > > EV_RETIRED > > EV_NOT_TAKEN > > EV_ALIGNMENT > > EV_PARTIAL_PREDICATE > > EV_EMPTY_PREDICATE > > > > I am just wander if we can use sample.transaction to store these event > > types, otherwise, we cannot distinguish the event type for the samples. > > If we can use the transaction field to distinguish sample types, I'm > wondering why we need the separate groups at all. If this new group > includes all sample types, and they're all labelled, do we need to > continue with the other groups like "tlb-access" and "branch-miss"? I admit the samples for "tlb-access" and "branch-miss" might not a good practice. At the time when I was upstreaming the Arm SPE patches (mainly based Hisilicon patches), the main idea for use some events to output samples, this is why "tlb-access" and "branch-miss" events were introduced. But when worked on Arm SPE for enabling "perf mem" and "perf c2c", I recognized that _consuming_ hardware trace data is much more important than merely outputting samples. A better way for _consuming_ the Arm SPE trace data is to synthesize samples with a prominent type and use an extra field in sample for the associated attribution. E.g. we can synthesize memory samples and uses field "sample.data_src" to distinguish different memory attributions, thus the events "tlb-access" and "branch-miss" are not useful. This approach can be applied to instruction event and branch event, and both of them use field "sample.flags" to indicate what's the type of instruction or branch. If we follow up this approach, below records can be considered to synthesize instruction or branch samples: EV_EXCEPTION_GEN EV_RETIRED EV_NOT_TAKEN Below records can be considered to generate memory samples: EV_ALIGNMENT EV_PARTIAL_PREDICATE EV_EMPTY_PREDICATE We can consider to extend sample's three fields: sample::flags for instruction/branch samples sample::data_srouce for memory samples sample::transaction for memory transactions (see macros with prefix PERF_TXN_). > Or does the perf GUI not allow filtering by transaction type? To be honest, when introduced the events "tlb-access" and "branch-miss", I didn't consider transaction type at all. Thanks, Leo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel