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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 E63D7C4338F for ; Tue, 27 Jul 2021 13:09:04 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id A98466128E for ; Tue, 27 Jul 2021 13:09:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A98466128E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XLjSe14k3npMX282Q8D5igPXW0a4dhLTXXSF0HLeIhU=; b=EKiNak+i1uBMdtnKNF7ieeRxoT PfytoqlxSL73PwzZoD3iYn5GkcXzZd15EzsrLtNB15RYDeZmx+8Az9YFa6xwqn5Iv5fA0SzO9y2j6 oD9e/SYAOPzXLa85i7D91y4Q+Ren2NTTgSjJ5g6NKdHy/myQKTtmI0qS+TPWg+ik0YSTpC48QF9NG t+hCg/o98eCfmJXZE/WYvV2cmgTilvOrLUKULrHRW9hiBw1Er322kKPCI2vWt+BfzDdZ9YkxTW4SX DtpJ1nnmdFMMMkm1BJn/tMl3qMx7EZx8wy5GSlyVyLpEySbXso738zu04Bx3uUADPP5QAPfNqVc6W fPWxGrlg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8MnC-00EnnF-L6; Tue, 27 Jul 2021 13:06:42 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8Mn9-00Enlf-1C for linux-arm-kernel@lists.infradead.org; Tue, 27 Jul 2021 13:06:40 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E62CD1FB; Tue, 27 Jul 2021 06:06:36 -0700 (PDT) Received: from [10.57.85.65] (unknown [10.57.85.65]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C2A1E3F66F; Tue, 27 Jul 2021 06:06:34 -0700 (PDT) Subject: Re: [PATCH v2 07/10] coresight: trbe: Do not truncate buffer on IRQ To: Mike Leach Cc: Coresight ML , linux-arm-kernel , Linux Kernel Mailing List , tamas.zsoldos@arm.com, Al Grant , Leo Yan , Mathieu Poirier , Anshuman Khandual , jinlmao@qti.qualcomm.com, James Clark , Peter Zijlstra , Will Deacon References: <20210723124611.3828908-1-suzuki.poulose@arm.com> <20210723124611.3828908-8-suzuki.poulose@arm.com> <064baefd-1213-1e54-20a0-b28f7565a810@arm.com> From: Suzuki K Poulose Message-ID: <278117cd-677d-c1be-b1e3-ea2a8825fcb1@arm.com> Date: Tue, 27 Jul 2021 14:06:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210727_060639_253858_AFBF9321 X-CRM114-Status: GOOD ( 39.93 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 27/07/2021 11:46, Mike Leach wrote: > HI Suzuki, > > On Mon, 26 Jul 2021 at 17:01, Suzuki K Poulose wrote: >> >> Hi Mike, >> >> On 26/07/2021 13:34, Mike Leach wrote: >>> Hi Suzuki, >>> >>> On Fri, 23 Jul 2021 at 13:46, Suzuki K Poulose wrote: >>>> >>>> The TRBE driver marks the AUX buffer as TRUNCATED when we get an IRQ >>>> on FILL event. This has rather unwanted side-effect of the event >>>> being disabled when there may be more space in the ring buffer. >>>> >>>> So, instead of TRUNCATE we need a different flag to indicate >>>> that the trace may have lost a few bytes (i.e from the point of >>>> generating the FILL event until the IRQ is consumed). Anyways, the >>>> userspace must use the size from RECORD_AUX headers to restrict >>>> the "trace" decoding. >>>> >>>> Using PARTIAL flag causes the perf tool to generate the >>>> following warning: >>>> >>>> Warning: >>>> AUX data had gaps in it XX times out of YY! >>>> >>>> Are you running a KVM guest in the background? >>>> >>>> which is pointlessly scary for a user. The other remaining options >>>> are : >>>> - COLLISION - Use by SPE to indicate samples collided >>>> - Add a new flag - Specifically for CoreSight, doesn't sound >>>> so good, if we can re-use something. >>>> >>> >>> What is the user visible behaviour when using COLLISION? >> >> If you meant a Warning from the perf tool (similar to TRUNCATE or >> PARTIAL), the answer is none. We could add one in the perf tool >> if you think this is necessary. >> > > I do - the problem is that we have replaced a visible warning with a > silent failure. > > While we agree that the side effects of TRUNCATE mean it unfeasible as > a solution here - at least the PARTIAL message does give some > indication. > The average perf user is going to rely on the output from the tool - > if there is no warning they will assume all is good, but they have > possible non-contiguous trace and no indication of such. > > Since we are using a collision flag in a particular context - i.e. > coresight trace - we have the chance to provide an appropriate message > for this context. > >>> The TRUNCATE warning is at least accurate - even if the KVM thing is >>> something of a red herring. >> > > Sorry - I meant PARTIAL here - but the comment stands otherwise. > >> >>> It is easier to explain a "scary" warning, than try to debug someones >>> problems if perf is silent or misleading when using the COLLISION >>> flag. >> >> The RECORD_AUX still has this flag. So, if someone really wanted to >> know how many times the TRBE fired the IRQ and thus potentially lost a >> few bytes of the trace, they could always look at this. >> > > They could - but how would they know that they needed to - what > indicators would they have that the trace was not continuous? > The point of the perf tool is that it presents an accurate picture to > the user, based on the data collected. Most users aren't going to > start digging into the intricacies of the perf data file formats and > nor should they have to. > >> Definitely this is not something similar to "TRUNCATED", which we >> realized the hard way, nor the PARTIAL. But the perf tool could >> report something similar. Please remember that the perf tool always >> uses the "size" field from the RECORD_AUX to limit the trace decoding. >> >> So, I am not sure how this could create new problems. >> > > There is no issue with decode - but if a user is investigating a > problem using trace, they need to be aware that some trace might be > dropped. > That way they can take mitigating action. Agreed. This is something that can be done by the perf tool. Kind regards Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel