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 977AAC52D7C for ; Mon, 19 Aug 2024 22:48:24 +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:Content-Transfer-Encoding: Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version: In-Reply-To:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=0mpr7864OCZvv9Hj0Yv++YX+VmARQzYZRUR5rU9bOeY=; b=iFozYD8gbbQMVpbbWLuYCCmnl8 3nuQMjzNVQLHG/7cuK1u9wmaP/74aBkrTQTZLpD9Rlxtv+AG40yfDS4q533y/ihGlVM2n4vL6ql6M COnq110+Aq/Gi809oYm8qOIjbW89B/JtiV5LA9n3n+JtkIDKEyWeS/XBkMtP7tC3AU2ztV3Y6vruI Z8Rf9vTzHD+K6+BEtamAJZTijCjw/TtctrwtK1dvCKDbvQqeoyzWIxw+/Phpq1I5sR4yVd/L5GsCz 3kC95LVushF1h7eu9cxMAm2ne4SuMFC43pbAlAUMMCTIEozmxYmzmVtfG76iW65z1o+cQ1DPe+lu8 MVUuo9+A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgBAT-000000039l3-01op; Mon, 19 Aug 2024 22:48:05 +0000 Received: from mail-pg1-x549.google.com ([2607:f8b0:4864:20::549]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgB9k-000000039cG-2tj9 for linux-arm-kernel@lists.infradead.org; Mon, 19 Aug 2024 22:47:22 +0000 Received: by mail-pg1-x549.google.com with SMTP id 41be03b00d2f7-6818fa37eecso4737942a12.1 for ; Mon, 19 Aug 2024 15:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724107639; x=1724712439; darn=lists.infradead.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=0mpr7864OCZvv9Hj0Yv++YX+VmARQzYZRUR5rU9bOeY=; b=LOymTV1i9NATo6Azr/Fabd+blEV7b6i/KfChwH8tKsZS9ZiCTyno0ctIQqi2tSpT26 vWeA1DDKtsKb0lq7xKDy62HW6j0Wf1eaMCitj1xr0D/F6aziYzC3RlPzykBV/3yTL8ZI cdhfSTbt7EEM0wEb4Azr+xb1ZtYVItOGGKu2ltgXKJgQLbGdT8zIzj+kXy9qK/EIyadC dYVTj6ufVVrq80nYOdUDTbbn53P/NvvsZ7rdOF/kDbSxVl/uI87/+VuJqsyIFvrYPg6B yNOgnmgWRZV8E+NKcN3wnU4lMt+38H73f1taZaFbUhtVNOC/FMpvxqRtm1t5sGQdD+t1 XPLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724107639; x=1724712439; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=0mpr7864OCZvv9Hj0Yv++YX+VmARQzYZRUR5rU9bOeY=; b=tbHEe/2x98WDx/I6aTUwcThVlCBOeSN4F+e++wnNhBK0Dzx72nRRv258rrxVD3m2Hc qn5rl4VG1qoAaysHfAbMebSpkZSNndztIc9OgBuEUjucw5HJCSGHvydzJcPSfPmklI32 2ZiPi+icB9cKlFNrmmTNO9zaBciiofc1fB2WuECBE4QRoTyz7eo1jQ3VMexwI8rKkbbS m8k3mS7n63I+GeKT24o/SmF8q46IPlF5Rc2B/Tj7rklZ03U076QsepMSjuV5Cc6NHXwQ dMsLeyTiATb7XE7hw2Z79LyPnzK1XDwCPQLdghT4B2vn8Y0y0tsBw4GS3g68K78NZ8jg eYKg== X-Forwarded-Encrypted: i=1; AJvYcCXr4jjkxDux1rwHkZWfJyaCvb9xI8Swg/QzHry6rvKxF8K2uSxUOTPLkRkBYNfgZEcEkJu8MxjK/JStaeT/Jp0h@lists.infradead.org X-Gm-Message-State: AOJu0Yx9eQvCW6yhRCghXkUiNczYr2gdoXoT83vI8ZZKMeQ/FcjK7PlF h/oB7900a3QL4jtjWydcVOW4rcqT4nwMgA38oAEZpT9Ofkej4Jp1GmYLaRHIE41bdHZPrj7kfkO hzw== X-Google-Smtp-Source: AGHT+IGngB58TyyXwtykQy2TchYmizV3K6F19AJubcP5aFPXxhvBteRSy0IDpLShOfEeLOPTdkLjdiTkkuE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:247:b0:1fd:8e8d:8695 with SMTP id d9443c01a7336-20203f27f39mr13121725ad.12.1724107638639; Mon, 19 Aug 2024 15:47:18 -0700 (PDT) Date: Mon, 19 Aug 2024 15:47:17 -0700 In-Reply-To: Mime-Version: 1.0 References: <20240724011037.3671523-1-jthoughton@google.com> <20240724011037.3671523-4-jthoughton@google.com> Message-ID: Subject: Re: [PATCH v6 03/11] KVM: arm64: Relax locking for kvm_test_age_gfn and kvm_age_gfn From: Sean Christopherson To: Oliver Upton Cc: Yu Zhao , James Houghton , Andrew Morton , Paolo Bonzini , Ankit Agrawal , Axel Rasmussen , Catalin Marinas , David Matlack , David Rientjes , James Morse , Jason Gunthorpe , 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240819_154720_781144_CCD67BE7 X-CRM114-Status: GOOD ( 16.43 ) 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 Mon, Aug 19, 2024, Oliver Upton wrote: > On Fri, Aug 16, 2024 at 07:03:27PM -0600, Yu Zhao wrote: > > On Fri, Aug 16, 2024 at 6:46=E2=80=AFPM Sean Christopherson wrote: >=20 > [...] >=20 > > > Were you expecting vCPU runtime to improve (more)? If so, lack of mo= vement could > > > be due to KVM arm64 taking mmap_lock for read when handling faults: > > > > > > https://lore.kernel.org/all/Zr0ZbPQHVNzmvwa6@google.com > >=20 > > For the above test, I don't think it's mmap_lock >=20 > Yeah, I don't think this is related to the mmap_lock. >=20 > James is likely using hardware that has FEAT_HAFDBS, so vCPUs won't > fault for an Access flag update. Huh, didn't know that was a thing on ARM. Ooh, that lends even more creden= ce to my assertion that marking folios accessed in handle_access_fault() can go a= way[*]. I assume hardware-assisted updates means this code in handle_access_fault()= will no longer be hit, as KVM simply won't ever get access faults? If so, I'll = add that info to the changelog. if (kvm_pte_valid(pte)) kvm_set_pfn_accessed(kvm_pte_to_pfn(pte)); [*] https://lore.kernel.org/all/20240726235234.228822-83-seanjc@google.com > Even if he's on a machine w/o it, Access flag faults are handled outside = the > mmap_lock. Oh, right, they go down handle_access_fault(), not user_mem_abort(). Reviewing late Friday afternoon, never a good idea ;-)