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 CC237C531DF for ; Wed, 14 Aug 2024 23:38:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49D936B008A; Wed, 14 Aug 2024 19:38:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4272F6B008C; Wed, 14 Aug 2024 19:38:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2EDA56B0092; Wed, 14 Aug 2024 19:38:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 112D36B008A for ; Wed, 14 Aug 2024 19:38:28 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A467C1A1211 for ; Wed, 14 Aug 2024 23:38:27 +0000 (UTC) X-FDA: 82452467454.12.F73AD3B Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) by imf10.hostedemail.com (Postfix) with ESMTP id B6B67C000E for ; Wed, 14 Aug 2024 23:38:25 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Ve8c9/nB"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf10.hostedemail.com: domain of oliver.upton@linux.dev designates 91.218.175.181 as permitted sender) smtp.mailfrom=oliver.upton@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723678652; a=rsa-sha256; cv=none; b=yz0Riryyr9HNvWXJ/L1w3swEP9x9E18TOabYxLwRVDPQMrPnc7qPsTFfnTv4v2DnZKHosC ErzbVTtLgZqxck0fOLUueyLILF3/Swzk7LcluExW2EbQU7T7twmtc6gOapsl40ttB4n4HS hs7eOHXz/xEDRCfdJCAjiN+wEMpjA2I= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Ve8c9/nB"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf10.hostedemail.com: domain of oliver.upton@linux.dev designates 91.218.175.181 as permitted sender) smtp.mailfrom=oliver.upton@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723678652; 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=SLPSCr45PlozEochk67KHBRJDoHMsgo62YtK7gKgkHM=; b=OnF/RHRykj3/tJvpjsQ6V9Z5RKS/Pbr3L3ipbN7YM1UivelzUYTvErCa1+89TLiYLw5/7u EddkuecpZWtVRQ9BODFUQCVP+f5iDK8mpK4osT0SWcZARxd2hBETsSuDK5sTrCqp4JXo/x G0aBLrMQA3OZkhY3CsqG5KVs1+n/3Dc= Date: Wed, 14 Aug 2024 16:38:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1723678703; 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=SLPSCr45PlozEochk67KHBRJDoHMsgo62YtK7gKgkHM=; b=Ve8c9/nB+Hba/Dde/QOYxHrDLOKPS2ZmDDFYjHKgvtnNyHOG7+y9ZJHQLRdeEplS/30s1C SaD3s5dPr7EUpuFyTiBHo1mu1PTYvszce0Xoi9ahGbnryIg/w2DqXF0ulU/B7Zl9W8ut2V Vlz4VNy6jjOStPZemVZCBdw0xivfjnU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sean Christopherson Cc: Jason Gunthorpe , Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador , Axel Rasmussen , linux-arm-kernel@lists.infradead.org, x86@kernel.org, Will Deacon , Gavin Shan , Paolo Bonzini , Zi Yan , Andrew Morton , Catalin Marinas , Ingo Molnar , Alistair Popple , Borislav Petkov , David Hildenbrand , Thomas Gleixner , kvm@vger.kernel.org, Dave Hansen , Alex Williamson , Yan Zhao , Marc Zyngier Subject: Re: [PATCH 00/19] mm: Support huge pfnmaps Message-ID: References: <20240809160909.1023470-1-peterx@redhat.com> <20240814123715.GB2032816@nvidia.com> <20240814144307.GP2032816@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: B6B67C000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 76gtm6ofxzsofdu4e38uane4mpni6d13 X-HE-Tag: 1723678705-268661 X-HE-Meta: U2FsdGVkX18OmJGeE5/KLh4lgPqREk6X13yFx/fzujaLXwCCV2k3ZNII/r2ZpN4SyvmK1sniTH0rlRFfEWFnewGg2G8EA3AOUc/psk2vCfq43gI90Bfr7nOuftkFhiRr+6C1lStM4WMrW7BIol3+B6a/toCRgIbmiE0p+sgH3kkG6VvleK21YHBWYGaxck15u/Pe+DXk5UTd+Cw5aTFLi6g4bN29L6jpeIbSeWosFQ8fx1GCORGL3ayc9TRcJPLm5nJYbwNNe0z+lt7ev7RYivYBPdb0WaQ9y0T+cgbt4s/ki0EkalILIkS5V8AuKekBb/cXam1mSkg6NiDfZDhhKY71ZT60UeBBT2+hy8UUvoQigY3JywOz3wkR1udiGxSr+ItJnRvChKhIdlS4Zc6GYjLh5c6SvpThmNsdmneyXbBZvxbel+j1dNebUGzyFixQzjaXmRz+CM10pgAgb1ov10qbOhOoGcYWm7YR5F8cmSKnJrzUV9As3/bDmrR7uTsAiprzGafbdKgLreuacePFko5HazVfC7qJNtImpEx1711rK9xHz7jiCEYwX+tPzJKvWxLOmuwJkdz7RGhBkmRqFaTFmT0DTRbIdy6RL070jn/5ySpvuLaUzj94Js+MXb0FZEBPoE0HYIOYQXjb/jcdpj5bnN/bweVU7IFNQ1OIhxfru3/d8muC5gDzk3myuHd24MkGoLHFFe+FsSBUa1BN4yvDjId7/3az5A4pi40UTphSYYUvYmNvz0xSVthAn3+3i6sYixobi8HOkQeO4BcB7VElfKmj+B/+7j50Pskcp4bB1MFDb/5FXJVNZ9G5llxnVhQQA3zSRb7suN1MDVz3iZIIQGYaIlqDTa1ju0g2Iga248MLlAq+YE8Grd9r3PaI/psIXK02jKjwDI/vQWw+AJg8/LYUicNRW4esIYRhZ9yYmnHFWSP+0CERzhw7MoRmL1IzJ+ElgBRMDZPGexe MuwDjHBn mcEQMDe7cRvd+JJlJMggM5/oeDbdaGQW+i+SSpiH88HUrob0hg9LsIhye5DTQ39GdO9vx4ZFfEJqL+UqaOTnkM4YneTXTk/TT8ybcyaPfSu6d2dAqk/q0JQ60OH1aqt5GJPu4 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, Aug 14, 2024 at 04:28:00PM -0700, Oliver Upton wrote: > On Wed, Aug 14, 2024 at 01:54:04PM -0700, Sean Christopherson wrote: > > TL;DR: it's probably worth looking at mmu_stress_test (was: max_guest_memory_test) > > on arm64, specifically the mprotect() testcase[1], as performance is significantly > > worse compared to x86, > > Sharing what we discussed offline: > > Sean was using a machine w/o FEAT_FWB for this test, so the increased > runtime on arm64 is likely explained by the CMOs we're doing when > creating or invalidating a stage-2 PTE. > > Using a machine w/ FEAT_FWB would be better for making these sort of > cross-architecture comparisons. Beyond CMOs, we do have some ... some heavy barriers (e.g. DSB(ishst)) we use to ensure page table updates are visible to the system. So there could still be some arch-specific quirks that'll show up in the test. > > and there might be bugs lurking the mmu_notifier flows. > > Impossible! :) > > > Jumping back to mmap_lock, adding a lock, vma_lookup(), and unlock in x86's page > > fault path for valid VMAs does introduce a performance regression, but only ~30%, > > not the ~6x jump from x86 to arm64. So that too makes it unlikely taking mmap_lock > > is the main problem, though it's still good justification for avoid mmap_lock in > > the page fault path. > > I'm curious how much of that 30% in a microbenchmark would translate to > real world performance, since it isn't *that* egregious. We also have > other uses for getting at the VMA beyond mapping granularity (MTE and > the VFIO Normal-NC hint) that'd require some attention too. > > -- > Thanks, > Oliver