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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09D6EC27C4F for ; Thu, 13 Jun 2024 06:50:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50A966B0082; Thu, 13 Jun 2024 02:50:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B9746B0098; Thu, 13 Jun 2024 02:50:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3331F6B0099; Thu, 13 Jun 2024 02:50:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0BA626B0082 for ; Thu, 13 Jun 2024 02:50:00 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AEFE1A05AC for ; Thu, 13 Jun 2024 06:49:59 +0000 (UTC) X-FDA: 82224940518.28.F28D5FF Received: from out-186.mta1.migadu.com (out-186.mta1.migadu.com [95.215.58.186]) by imf09.hostedemail.com (Postfix) with ESMTP id 3A64314000B for ; Thu, 13 Jun 2024 06:49:55 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=M9CSiT8d; spf=pass (imf09.hostedemail.com: domain of oliver.upton@linux.dev designates 95.215.58.186 as permitted sender) smtp.mailfrom=oliver.upton@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718261396; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dUgr+f5/S1BYrMzUIzzHoZq+nuXyyf5V0WdYC25Cd8s=; b=FnUQgrZLESWWiGs/i8d2GH3wlHcQvw960ra1SaO8zakF+g+M31UbaNohV+jecQVMAHn6fJ JaooNaf5oXGMP/2wKi/0HTnc7qXgcKCe4tek9Z4YIqmi3/crE8AZ/tBUYuxr4ItoalRuUR xzHD8Nd7/fsHyoEDOC/X99dGeRAcpKw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=M9CSiT8d; spf=pass (imf09.hostedemail.com: domain of oliver.upton@linux.dev designates 95.215.58.186 as permitted sender) smtp.mailfrom=oliver.upton@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718261396; a=rsa-sha256; cv=none; b=d4N7uqmxfjQg+ijot9ILqTaDpMYzXkkEGPBDVQdwcDnUnhMjL31w1KEwVArfC6GCuSU/C/ czX+rIzYKT3S2N6s7i2kPLinc230RhOuysC5Exfa+GjPxkFnflrSVfPTvnyMgZPmeZsVNR urlhtfLMqU6/mlpCRM6kX1O1FXzFjEI= X-Envelope-To: seanjc@google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1718261393; 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=dUgr+f5/S1BYrMzUIzzHoZq+nuXyyf5V0WdYC25Cd8s=; b=M9CSiT8dKaHTw3piv1V6oTj1KqOQyfs8CvaI3RQ5vdJYFt99RH8vNd3LFbE9PIVk8OwVas XLz0PROCqSuYLAzNwIijJmurJ/2zA913Ie50WmEJwiiEM6WIAqspuiwNr8jfX+PHrPS0PA FrxV+3EAzC1TIsW+x5UmXdQ/vywRTBQ= X-Envelope-To: yuzhao@google.com X-Envelope-To: jthoughton@google.com X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: pbonzini@redhat.com X-Envelope-To: ankita@nvidia.com X-Envelope-To: axelrasmussen@google.com X-Envelope-To: catalin.marinas@arm.com X-Envelope-To: dmatlack@google.com X-Envelope-To: rientjes@google.com X-Envelope-To: james.morse@arm.com X-Envelope-To: corbet@lwn.net X-Envelope-To: maz@kernel.org X-Envelope-To: rananta@google.com X-Envelope-To: ryan.roberts@arm.com X-Envelope-To: shahuang@redhat.com X-Envelope-To: suzuki.poulose@arm.com X-Envelope-To: weixugc@google.com X-Envelope-To: will@kernel.org X-Envelope-To: yuzenghui@huawei.com X-Envelope-To: kvmarm@lists.linux.dev X-Envelope-To: kvm@vger.kernel.org X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: linux-doc@vger.kernel.org X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: linux-mm@kvack.org Date: Wed, 12 Jun 2024 23:49:43 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sean Christopherson Cc: Yu Zhao , James Houghton , Andrew Morton , Paolo Bonzini , Ankit Agrawal , Axel Rasmussen , Catalin Marinas , David Matlack , David Rientjes , James Morse , Jonathan Corbet , Marc Zyngier , Raghavendra Rao Ananta , Ryan Roberts , Shaoqin Huang , Suzuki K Poulose , Wei Xu , Will Deacon , Zenghui Yu , kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v5 8/9] mm: multi-gen LRU: Have secondary MMUs participate in aging Message-ID: References: <20240611002145.2078921-1-jthoughton@google.com> <20240611002145.2078921-9-jthoughton@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 3A64314000B X-Stat-Signature: 1ger7ptjkei5opxj6br7g4b9gs5g5d35 X-HE-Tag: 1718261395-861847 X-HE-Meta: U2FsdGVkX1+2OwymmaZrSoEozTKuTREGJ6q4n3Af2zcqqPLNWZPTS4RJ34xWp8rI8xQc2hr2jeeEkczKDibQlFMbLcT7m6yv+abI0sb/CPGOaskKva92m+6HVAV1kb+NcNIwtzy5hxyy1wv+UL27WMgxrXAbuk9F0oIqVOnerc+iWzozlp/dLlBCTObKpokbZiw6xhiHmB778Ct7gJyakKGu7t3qMc4jfOJHM6wwhzSa+Qp9/3fLN1d05Lx1CdzXPE0BvFwD6T/3C6LTmy2HZjjn5cazgOcpv8dBpgXj4eKW66qc6LEu1jd7I3wwvFnC5ZhoRwoeCNzUdPlpCs+fBu0A3gUMMGB26cnPKDY+Lq8Ysy+JweYD7HqNxBOy50jY1mxd9TN+A4NYRYlwfRa5dXi1wYf18JG/USZ5lLjcgL0XXJhAQGYaxNAC+JJhb7U2uPvSuWq+1ULN/v5IU1twbZAuFE+6UlB06cDp+a1JKNgJ1Y2MByll/D/56TE2iX51XOI/0jcFFboKaSLe/dg+B6CfPDVw5cEMucZaIdbFDCozR1852YVasW912hkQRUK+PsvbdlAhvk6nY8wvr6TzLCKXnasuBQ6QmvqxAdXlqEEFknm2X/PAPFnm826Kh+C4u5Ea0CP+tmS+KSbVl6CIgVkXydEdHHVXL1OQBBFTAgQSx0M82duYFTkz+cAqhNn5Y3P0hONWmoi0+zKwEDIDo4I9BEDzie+dsvTCWeJWd6ovfOOCNw3hFTG/zltETxrJoJ63sAg8bibq+PFHFS150HzarqEfcArs6ZLfSzKRsZlr6SkU/vT4ARDynz8oPkkaVt0HCHfDcAXf9Xi+3BRxop+2d9Zr93Rix3HbL2z+Ql5OuR4lkNkkWN/oajzrAxpehdRGn8LhNcQSysnFeQD2sibdvju56p8cI7ETkUv1zpWppHR6T7WR2hES4rT+r++vQpBssnI/7U0ohuGjmWh ts+jtWBE 3pIZIlbNA8m5N/L9KOyoa8so5HVi5gt2TrKVV/N701C/1k2ptpuKc2R06hq1GFFq53UB17zIf+qOOq01IsKP9Ve/WNzF+qJxn6iPAnrZTNGjm6PD8kdQdHTad8Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Jun 12, 2024 at 10:23:38AM -0700, Sean Christopherson wrote: > On Wed, Jun 12, 2024, Yu Zhao wrote: > > I do think there can be false negatives but we have not been able to > > measure their practical impacts since we disabled the flush on some > > host MMUs long ago (NOT by MGLRU), e.g., on x86 and ppc, > > ptep_clear_flush_young() is just ptep_test_andclear_young(). > > Aha! That's what I was missing, I somehow didn't see x86's ptep_clear_flush_young(). Heh, well the helper name isn't exactly giving any hints... > That begs the question, why does KVM flush TLBs on architectures that don't need > to? And since kvm_mmu_notifier_clear_young() explicitly doesn't flush, are there > even any KVM-supported architectures for which the flush is mandatory? > > Skipping the flush on KVM x86 seems like a complete no-brainer. > > Will, Marc and/or Oliver, what are arm64's requirements in this area? E.g. I see > that arm64's version of __ptep_clear_flush_young() does TLBI but not DSB. Should > KVM be doing something similar? Can KVM safely skip even the TBLI? Short answer, yes, KVM can elide TLBIs when clearing AF. Long answer: Software needs to be extremely careful to ensure that TLBI elision doesn't lead to a failure to uphold break-before-make requirements, if we're only concerned with architecture-specific requirements. IOW, the AF cannot be used as a hint for the presence of TLB entries for a given PTE. There's the obvious failure of skipping TLBIs for old pages when unmapping, but that isn't an architecture-specific issue. So, since KVM/arm64 doesn't play any games with the AF at stage-2, leaving out a TLBI when aging ought to be fine. -- Thanks, Oliver