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.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 827CCC41604 for ; Tue, 6 Oct 2020 15:32:36 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id CFEB5206DD for ; Tue, 6 Oct 2020 15:32:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="xF4QzW2B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CFEB5206DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5242D4B950; Tue, 6 Oct 2020 11:32:35 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpyVr8H6ReUb; Tue, 6 Oct 2020 11:32:31 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D92504B883; Tue, 6 Oct 2020 11:32:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id CA65E4B883 for ; Tue, 6 Oct 2020 11:32:30 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egmd8qZZLeDc for ; Tue, 6 Oct 2020 11:32:29 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id B59074B881 for ; Tue, 6 Oct 2020 11:32:29 -0400 (EDT) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 72155206D4; Tue, 6 Oct 2020 15:32:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601998348; bh=GfZ6DJS7+/fzU/LHMs3uF4eCQH/eBFHlwG6EvCYtUhE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xF4QzW2BajiFTZWRXtIVU8iQaSbjfqMFeUz/nb1v7m88tzvTPkc3bH4XmvDJapGCF +UL77ytTod7I6KIeu7Of3BtqoHtYm8lU3Vj/XSvXvHD/0WbbnfvEY33MeLKjuMyzuS ll59z4HmsfWnzAFhjocn5Zft4RjkWDcyZILPsv6o= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kPox0-0006k8-Bi; Tue, 06 Oct 2020 16:32:26 +0100 Date: Tue, 06 Oct 2020 16:32:18 +0100 Message-ID: <87ft6r4bgd.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Subject: Re: [PATCH] perf: arm_spe: Use Inner Shareable DSB when draining the buffer In-Reply-To: <20201006150520.161985-1-alexandru.elisei@arm.com> References: <20201006150520.161985-1-alexandru.elisei@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26.3 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: catalin.marinas@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, will@kernel.org, kvmarm@lists.cs.columbia.edu X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Alex, On Tue, 06 Oct 2020 16:05:20 +0100, Alexandru Elisei wrote: > > From ARM DDI 0487F.b, page D9-2807: > > "Although the Statistical Profiling Extension acts as another observer in > the system, for determining the Shareability domain of the DSB > instructions, the writes of sample records are treated as coming from the > PE that is being profiled." > > Similarly, on page D9-2801: > > "The memory type and attributes that are used for a write by the > Statistical Profiling Extension to the Profiling Buffer is taken from the > translation table entries for the virtual address being written to. That > is: > - The writes are treated as coming from an observer that is coherent with > all observers in the Shareability domain that is defined by the > translation tables." > > All the PEs are in the Inner Shareable domain, use a DSB ISH to make sure > writes to the profiling buffer have completed. I'm a bit sceptical of this change. The SPE writes are per-CPU, and all we are trying to ensure is that the CPU we are running on has drained its own queue of accesses. The accesses being made within the IS domain doesn't invalidate the fact that they are still per-CPU, because "the writes of sample records are treated as coming from the PE that is being profiled.". So why should we have an IS-wide synchronisation for accesses that are purely local? M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 50459C41604 for ; Tue, 6 Oct 2020 15:34:01 +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 EA8B0206D4 for ; Tue, 6 Oct 2020 15:34:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Q2Wb//Y+"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="xF4QzW2B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA8B0206D4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:MIME-Version:References:In-Reply-To:Subject:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=CtK7uF3bPlq2defJCW1JcwGaS3rASSUNg4r1vBCEeOQ=; b=Q2Wb//Y+rzSbE3r6k+RLnUGb0 GpNL0RU7FLbYQ4mZ0cqpHn/n/R09LaI3v2kTumYJzYMBzlLFbZGhbn8DiA9RvdRJA55wBDTPb48m/ YmFsJcRcbuTfDRSULu+znoMvnL7B329Z2ikL40RugrFTVRi/B96pivFYUgz81pBs1eQiIIR80ev92 3+NwsR6n93g0Z+V6puiMYxwjzHsp6PlTVnecZyf2jjPanqI4Z9hMjZIGsKrpk0TLoKNiru0Cwbmnx Drcy5l5gHkCBQWTglRzrJZovZc4kzvgBrGq/wPB7RVYglF3nNRtKXlXsB9GjTW/Ai5GWkAwsgPf4R TtqbT6gDg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPox7-00086T-Qj; Tue, 06 Oct 2020 15:32:33 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPox5-00085r-5W for linux-arm-kernel@lists.infradead.org; Tue, 06 Oct 2020 15:32:32 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 72155206D4; Tue, 6 Oct 2020 15:32:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601998348; bh=GfZ6DJS7+/fzU/LHMs3uF4eCQH/eBFHlwG6EvCYtUhE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xF4QzW2BajiFTZWRXtIVU8iQaSbjfqMFeUz/nb1v7m88tzvTPkc3bH4XmvDJapGCF +UL77ytTod7I6KIeu7Of3BtqoHtYm8lU3Vj/XSvXvHD/0WbbnfvEY33MeLKjuMyzuS ll59z4HmsfWnzAFhjocn5Zft4RjkWDcyZILPsv6o= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kPox0-0006k8-Bi; Tue, 06 Oct 2020 16:32:26 +0100 Date: Tue, 06 Oct 2020 16:32:18 +0100 Message-ID: <87ft6r4bgd.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Subject: Re: [PATCH] perf: arm_spe: Use Inner Shareable DSB when draining the buffer In-Reply-To: <20201006150520.161985-1-alexandru.elisei@arm.com> References: <20201006150520.161985-1-alexandru.elisei@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26.3 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201006_113231_284230_DAC00FC3 X-CRM114-Status: GOOD ( 20.95 ) 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: mark.rutland@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, will@kernel.org, kvmarm@lists.cs.columbia.edu, julien.thierry.kdev@gmail.com 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 Alex, On Tue, 06 Oct 2020 16:05:20 +0100, Alexandru Elisei wrote: > > From ARM DDI 0487F.b, page D9-2807: > > "Although the Statistical Profiling Extension acts as another observer in > the system, for determining the Shareability domain of the DSB > instructions, the writes of sample records are treated as coming from the > PE that is being profiled." > > Similarly, on page D9-2801: > > "The memory type and attributes that are used for a write by the > Statistical Profiling Extension to the Profiling Buffer is taken from the > translation table entries for the virtual address being written to. That > is: > - The writes are treated as coming from an observer that is coherent with > all observers in the Shareability domain that is defined by the > translation tables." > > All the PEs are in the Inner Shareable domain, use a DSB ISH to make sure > writes to the profiling buffer have completed. I'm a bit sceptical of this change. The SPE writes are per-CPU, and all we are trying to ensure is that the CPU we are running on has drained its own queue of accesses. The accesses being made within the IS domain doesn't invalidate the fact that they are still per-CPU, because "the writes of sample records are treated as coming from the PE that is being profiled.". So why should we have an IS-wide synchronisation for accesses that are purely local? M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-4.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 113FBC41604 for ; Tue, 6 Oct 2020 15:32:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B7C53206F7 for ; Tue, 6 Oct 2020 15:32:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601998350; bh=GfZ6DJS7+/fzU/LHMs3uF4eCQH/eBFHlwG6EvCYtUhE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=aU6Hwpz6bX6mqBxymNHQ7UJRiBhN6svhYqH1wWA4K+inElp2POEVTDlsV7ZlyZRb8 EqhMdnR19k9xlJb5HqFGrdIGxdOPRZLKbAf3+lbHeFltuHtYr2kIYBi71EwtMyjCFI qILmB97sNAhuDH3HimA6mKh8JT612bwcBy/TSce8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726181AbgJFPc3 (ORCPT ); Tue, 6 Oct 2020 11:32:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:57416 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725769AbgJFPc3 (ORCPT ); Tue, 6 Oct 2020 11:32:29 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 72155206D4; Tue, 6 Oct 2020 15:32:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601998348; bh=GfZ6DJS7+/fzU/LHMs3uF4eCQH/eBFHlwG6EvCYtUhE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xF4QzW2BajiFTZWRXtIVU8iQaSbjfqMFeUz/nb1v7m88tzvTPkc3bH4XmvDJapGCF +UL77ytTod7I6KIeu7Of3BtqoHtYm8lU3Vj/XSvXvHD/0WbbnfvEY33MeLKjuMyzuS ll59z4HmsfWnzAFhjocn5Zft4RjkWDcyZILPsv6o= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kPox0-0006k8-Bi; Tue, 06 Oct 2020 16:32:26 +0100 Date: Tue, 06 Oct 2020 16:32:18 +0100 Message-ID: <87ft6r4bgd.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com Subject: Re: [PATCH] perf: arm_spe: Use Inner Shareable DSB when draining the buffer In-Reply-To: <20201006150520.161985-1-alexandru.elisei@arm.com> References: <20201006150520.161985-1-alexandru.elisei@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26.3 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alex, On Tue, 06 Oct 2020 16:05:20 +0100, Alexandru Elisei wrote: > > From ARM DDI 0487F.b, page D9-2807: > > "Although the Statistical Profiling Extension acts as another observer in > the system, for determining the Shareability domain of the DSB > instructions, the writes of sample records are treated as coming from the > PE that is being profiled." > > Similarly, on page D9-2801: > > "The memory type and attributes that are used for a write by the > Statistical Profiling Extension to the Profiling Buffer is taken from the > translation table entries for the virtual address being written to. That > is: > - The writes are treated as coming from an observer that is coherent with > all observers in the Shareability domain that is defined by the > translation tables." > > All the PEs are in the Inner Shareable domain, use a DSB ISH to make sure > writes to the profiling buffer have completed. I'm a bit sceptical of this change. The SPE writes are per-CPU, and all we are trying to ensure is that the CPU we are running on has drained its own queue of accesses. The accesses being made within the IS domain doesn't invalidate the fact that they are still per-CPU, because "the writes of sample records are treated as coming from the PE that is being profiled.". So why should we have an IS-wide synchronisation for accesses that are purely local? M. -- Without deviation from the norm, progress is not possible.