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 86EBFC3DA5D for ; Fri, 19 Jul 2024 15:16:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=PAQuHshHUyfYgFLJbuvQs9agkb4OM0cf5/CJu/pDDvc=; b=Kbm0ePQZHlZpZtH20WhgYHOQ+O 7xkBEwPDItcVIBZrIvMBxL7SKIpNX+M4vPc0agj5q7P2XBftzOULP/1DQwHspEfEr57AiUXhiHo45 QmubAkTOJBnxoyFNzx0KAEhGAog9f3GJSV9NF/4Yl+TtzvQUjBUgiZKtx0OFegTQdI5Hxezzqf3yt +WcEJKB0gjARmBSHk8Y2WIz7x1qpui20jB0+VJkYnCtpJQXWqFX1XlSBAqxbAWSV5kpjo2rQDkJz1 MGoPHl1qA5gel0IIt6WG/G2TPKRDQMzWTQKN4rgauBZcsfi5jzh+ix4UeEzV2Xy1hKwIavaSeHRGx zmsRmsWQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sUpKl-000000033mp-0guQ; Fri, 19 Jul 2024 15:15:47 +0000 Received: from out-185.mta0.migadu.com ([2001:41d0:1004:224b::b9]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sUpKP-000000033gY-0PVw for linux-arm-kernel@lists.infradead.org; Fri, 19 Jul 2024 15:15:27 +0000 X-Envelope-To: coltonlewis@google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1721402120; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PAQuHshHUyfYgFLJbuvQs9agkb4OM0cf5/CJu/pDDvc=; b=NbqaaX+AoiTKB6AilVIQfAGASOmSzu18lsVoSK2FBH19PAfvHgJ3lZ8WaC9c817ThB9sHk ZzlJFzHmZlIISb0zj940TTxdE1H7Kep6O7SP5RLxmTAmVWmi4UHfnwD0IMxYDKdo37JlW8 DPgyC/VUUmc6D7lRUJ5siYKzRLlocLI= X-Envelope-To: kvm@vger.kernel.org X-Envelope-To: maz@kernel.org X-Envelope-To: james.morse@arm.com X-Envelope-To: suzuki.poulose@arm.com X-Envelope-To: yuzenghui@huawei.com X-Envelope-To: catalin.marinas@arm.com X-Envelope-To: will@kernel.org X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: kvmarm@lists.linux.dev X-Envelope-To: linux-kernel@vger.kernel.org Date: Fri, 19 Jul 2024 08:15:14 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Colton Lewis Cc: kvm@vger.kernel.org, Marc Zyngier , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Move data barrier to end of split walk Message-ID: References: <20240718223519.1673835-1-coltonlewis@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240718223519.1673835-1-coltonlewis@google.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240719_081525_540354_BB82E212 X-CRM114-Status: GOOD ( 12.32 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 18, 2024 at 10:35:19PM +0000, Colton Lewis wrote: > Moving the data barrier from stage2_split_walker to after the walk is > finished in kvm_pgtable_stage2_split results in a roughly 70% > reduction in Clear Dirty Log Time in dirty_log_perf_test (modified to > use eager page splitting) when using huge pages. This gain holds > steady through a range of vcpus used (tested 1-64) and memory > used (tested 1-64GB). > > This is safe to do because nothing else is using the page tables while > they are still being mapped and this is how other page table walkers > already function. None of them have a data barrier in the walker > itself. nitpick: in the interest of the reader, it'd be a good idea to state explicitly what purpose the DSB serves, which is to guarantee page table updates have been made visible to hardware table walker. Relative ordering of table PTEs to table contents comes from the fact that stage2_make_pte() has release semantics. -- Thanks, Oliver