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=-3.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 DE2A3C388F9 for ; Tue, 27 Oct 2020 13:15:54 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 66F5F20754 for ; Tue, 27 Oct 2020 13:15:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="NYoZxuf8"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="tvtZZIii" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 66F5F20754 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6nzxB2o1fCAA9O2TmFLCAOpzU+lTPXxKdsNQW2hoP7k=; b=NYoZxuf8Tepcig7aizFSyjUHA QA+ZRdVdiw91GqvPLaneEbVXHwX0FEev59LmHbvZrNIQP2zqewzzNK2yOaSHWNawVBm1gCRq7mJTI GrkFaIEhUSk/fnZ2RVH12mCDRYRwQfT/a/pDokrIvPf3kJtFIH0K5kd2JVqIPMbjX8gCkeuxS2lGQ Z+8nNIhrHCXf6Qsdz+GoLhGlo/WHhDxhM/o73BOR6rdAfzJ1rgJdetzMjSxuJ7JVwLWbotoYJ4X0d G8fxeNtOdNKiZjfZ8WcbIBb+GqTKeFTEBp8Nf8bAJMNK11MQ+hxQgaiabTqYCfurhJI21jjZKZkPs hadL7FZ4w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXOnb-0002er-I0; Tue, 27 Oct 2020 13:14:03 +0000 Received: from mail-lj1-x241.google.com ([2a00:1450:4864:20::241]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXOnW-0002e6-6e for linux-arm-kernel@lists.infradead.org; Tue, 27 Oct 2020 13:13:59 +0000 Received: by mail-lj1-x241.google.com with SMTP id c21so1736147ljj.0 for ; Tue, 27 Oct 2020 06:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a4c7biyubMcO/yRXpuquLWN6v783s6N7+AqfcWKJ6pQ=; b=tvtZZIii0KvUztaxyvAXaJIN8SV4yYK3QfWuJX3jHJ7tLCbMlLTpe7NtWkH73ykgf2 JZSJOkz6dQrpgZelSIuIeDQvMKBopV6zdl5epxfun++Sw445qc5b/JX0bBuqkEurE4hH 6DDx+87BXQaSDdlPSKqD7K4PjUBTRXTAWTrOZmcU2olujsFdseK/eIRJ4ucnFLaRw+K2 whukgK60rqyX9pSbti/TS+ld/xAjTVdm++m5jHcFCTc09xj817gpFFdTfE6D8tZwcQkC VY7JeHDXuDUMkXotMhF7TfMAGfnE7q4YrbaITYvqhhn97+A473YaV7lLL0rLwY8ehYNa d7jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a4c7biyubMcO/yRXpuquLWN6v783s6N7+AqfcWKJ6pQ=; b=ikPhmlJnszgptG/By+aFNurdj4BA9oGq+PUqP7lF2zmcBqj/3mONb7ARuDXa+NWnlv lgIfmw6Zk5EI1uYQIKY1aPkVkumGGxuqP/VdYkkMBZsxY6P5+N6iO4jfH+lpnuLy4vmk bD6xVz05U31JSwf1Wyij1fm8pZ/hrIctfGy8UVlnh+OD6qJRmXECTDeDVfZP4IbylbhE 5z0h914UNwSRkJUqpXWLvWMgaaV7O6hqFTTA5BX6yXeoWKwXycg121MrgR0D5klHtN6+ D4bMWgzF5i74rcVE2YFN1CoWVH2FFDm6s+4japNztcVgdEAZ8IIzb5aNFprhLGx9LQZF 8zBA== X-Gm-Message-State: AOAM531YsDFvz7CdbDAJsW2IfkM767AKhITmXi8n1gVOhEDa94GH0K87 /vH9SZHcujRY4AqjQABfTPCbK4BxlCndUPE7uWI= X-Google-Smtp-Source: ABdhPJyivZ3mzyPHHEk+ydYQN6fFOwDfEfxfNir/1M/MdfpYtK4m+2L4y1vIlDu9mpMF/BNVz+XFPa66QIb7Q4xpfi8= X-Received: by 2002:a2e:80d7:: with SMTP id r23mr1142309ljg.390.1603804435199; Tue, 27 Oct 2020 06:13:55 -0700 (PDT) MIME-Version: 1.0 References: <20200904024106.21478-1-lcherian@marvell.com> <2bd65f2d-5660-10b3-f51f-448221d78d3d@arm.com> In-Reply-To: From: Linu Cherian Date: Tue, 27 Oct 2020 18:43:42 +0530 Message-ID: Subject: Re: [PATCH v4 0/2] Make sysFS functional on topologies with per core sink To: Suzuki K Poulose X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201027_091358_309358_19603C9C X-CRM114-Status: GOOD ( 28.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel , Coresight ML , Mathieu Poirier , Linu Cherian , Mike Leach 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 Suzuki, On Mon, Oct 26, 2020 at 11:47 PM Suzuki K Poulose wrote: > > Hi Linu, > > Thanks for the feedback. My responses inline. > > On 10/26/20 4:33 AM, Linu Cherian wrote: > > Hi Suzuki, > > > > On Mon, Oct 5, 2020 at 4:52 PM Suzuki K Poulose wrote: > >> > >> Hi Linu, > >> > >> On 09/04/2020 03:41 AM, Linu Cherian wrote: > >>> This patch series tries to fix the sysfs breakage on topologies > >>> with per core sink. > >>> > >>> Changes since v3: > >>> - References to coresight_get_enabled_sink in perf interface > >>> has been removed and marked deprecated as a new patch. > >>> - To avoid changes to coresight_find_sink for ease of maintenance, > >>> search function specific to sysfs usage has been added. > >>> - Sysfs being the only user for coresight_get_enabled sink, > >>> reset option is removed as well. > >> > >> Have you tried running perf with --per-thread option ? I believe > >> this will be impacted as well, as we choose a single sink at the > >> moment and this may not be reachable from the other CPUs, where > >> the event may be scheduled. Eventually loosing trace for the > >> duration where the task is scheduled on a different CPU. > >> > >> Please could you try this patch and see if helps ? I have lightly > >> tested this on a fast model. > > > > We are seeing some issues while testing with this patch. > > The issue is that, always buffer allocation for the sink happens to be on the > > first core in cpu mask and this doesn't match with the core on which > > event is started. Please see below for additional comments. > > Please could you clarify the "issues" ? How is the buffer allocation > a problem ? 1. Just realized that the issue that we are seeing with this patch is something specific to our test setup, since we had some custom patches that was required for supporting the secure trace buffer configuration for our silicon. And to be specific, our changeset was relying on the drvdata->etr_buf at the time of tmc_etr_sync_perf_buffer. In per core case during buffer allocation, the sink chosen is always for the first core, core 0. Let's consider the event started on say, core 4. So w.r.t drvdata of tmc_etr4, drvdata->etr_buf would get initialized while starting the event. And w.r.t drvdata of tmc_etr0, drvdata->etr_buf would be NULL here and our custom changeset was expecting to be initialized with the etr_buf. So will try to rebase our patches accordingly and test this again. 2. Related to iommu enabled configuration. This on the assumption that there can be dedicated stream id (device id) possible for each per core ETR device. Please ignore otherwise. When the buffer allocation happens on tmc_etr0, and provided we have a iommu enabled case, the iommu mapping would be w.r.t to tmc_etr0. But then, the actual DMA might get triggered from a non matching device, ie. tmc_etr4 which would then fail. Should we take this into consideration ? Thanks. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel