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=-8.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 7B031C433E1 for ; Thu, 16 Jul 2020 10:21:58 +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 459AD204EA for ; Thu, 16 Jul 2020 10:21:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="2QYHHiU1"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="xkehWQ0P" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 459AD204EA 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:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=DsehBx0Cfek4C5/YXbhRmqX786UJcjLRZyV/L/yKV7U=; b=2QYHHiU1cMrHUueK7qOwUi9aG h/U9cAHWMS5Nw178LyQqbpsa8I1FCxs/FrdN9Hm0f2Y6fkj0PJrJtX5ifl0TdIvJ4G6mGJhQGetwu fkKUY2J3Thrl+EWdaNRPq4dI8IohIUfX/y8sUUCkfDjXIlu3fCmkl7753G0a+URLigT+8njmMAg7Q /7HjtXbrvO0mgnFDVc6JZNshptvcT7vO7dsev5AljX1+DRVkmkVAsV3Tah8qpva0CV6W/wk250/60 I4LDv48E+83y/v0RElKvl2xKpHgyEFdRv7WZM5R07EQB/qyAvCmvldIqMc2BM7I0PhGrXoVMvEvye dDPYm5Tsw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jw10Q-00040F-CD; Thu, 16 Jul 2020 10:20:46 +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 1jw10N-0003zK-1q for linux-arm-kernel@lists.infradead.org; Thu, 16 Jul 2020 10:20:43 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (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 E8713204EA; Thu, 16 Jul 2020 10:20:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594894842; bh=L6O+9oJn1klewKnv0PBbNlZZnruWJcrOzt9QTNHkA/U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xkehWQ0P7hppEt6KHlYUlNGEAJM8OiWVyU/FFxdOlbHSDDRGF+SH3gG1B2UeSdM5T DeZueDeBk9N0QcPGSM1Gli43+RB8GbBsIzFd8GKMiWXeKYbhxuukGgUQzYqY1EjCJo nHXYGPB7Ds3TZpJVZ6Vp/uNo++ewbKViKu8zEbwg= Date: Thu, 16 Jul 2020 11:20:38 +0100 From: Will Deacon To: John Garry Subject: Re: [PATCH 4/4] iommu/arm-smmu-v3: Remove cmpxchg() in arm_smmu_cmdq_issue_cmdlist() Message-ID: <20200716102037.GB7036@willie-the-truck> References: <1592846920-45338-1-git-send-email-john.garry@huawei.com> <1592846920-45338-5-git-send-email-john.garry@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1592846920-45338-5-git-send-email-john.garry@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200716_062043_225051_3D53075D X-CRM114-Status: GOOD ( 24.84 ) 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: trivial@kernel.org, maz@kernel.org, joro@8bytes.org, linux-kernel@vger.kernel.org, linuxarm@huawei.com, iommu@lists.linux-foundation.org, robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org 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 Tue, Jun 23, 2020 at 01:28:40AM +0800, John Garry wrote: > It has been shown that the cmpxchg() for finding space in the cmdq can > be a bottleneck: > - for more CPUs contending the cmdq, the cmpxchg() will fail more often > - since the software-maintained cons pointer is updated on the same 64b > memory region, the chance of cmpxchg() failure increases again > > The cmpxchg() is removed as part of 2 related changes: > > - Update prod and cmdq owner in a single atomic add operation. For this, we > count the prod and owner in separate regions in prod memory. > > As with simple binary counting, once the prod+wrap fields overflow, they > will zero. They should never overflow into "owner" region, and we zero > the non-owner, prod region for each owner. This maintains the prod > pointer. > > As for the "owner", we now count this value, instead of setting a flag. > Similar to before, once the owner has finished gathering, it will clear > a mask. As such, a CPU declares itself as the "owner" when it reads zero > for this region. This zeroing will also clear possible overflow in > wrap+prod region, above. > > The owner is now responsible for all cmdq locking to avoid possible > deadlock. The owner will lock the cmdq for all non-owers it has gathered > when they have space in the queue and have written their entries. > > - Check for space in the cmdq after the prod pointer has been assigned. > > We don't bother checking for space in the cmdq before assigning the prod > pointer, as this would be racy. > > So since the prod pointer is updated unconditionally, it would be common > for no space to be available in the cmdq when prod is assigned - that > is, according the software-maintained prod and cons pointer. So now > it must be ensured that the entries are not yet written and not until > there is space. > > How the prod pointer is maintained also leads to a strange condition > where the prod pointer can wrap past the cons pointer. We can detect this > condition, and report no space here. However, a prod pointer progressed > twice past the cons pointer cannot be detected. But it can be ensured that > this that this scenario does not occur, as we limit the amount of > commands any CPU can issue at any given time, such that we cannot > progress prod pointer further. > > Signed-off-by: John Garry > --- > drivers/iommu/arm-smmu-v3.c | 101 ++++++++++++++++++++++-------------- > 1 file changed, 61 insertions(+), 40 deletions(-) I must admit, you made me smile putting trivial@kernel.org on cc for this ;) Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel