Received: by 2002:ab2:6203:0:b0:1f5:f2ab:c469 with SMTP id o3csp930883lqt; Fri, 19 Apr 2024 15:24:05 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXjO2bagQSb4HZGttO3pwOAx9SqlWEVpwQIFUDXXedE9xjGKFucqe2bp2hFE2THcD1AG5Dlg9eNXhsoaOSljGKUG6wM0WWQkLkT/53CCA== X-Google-Smtp-Source: AGHT+IFqTsWe4TXPqLEYF1Cs6dy2mQ7CDvCmEcSdkGE4QovB2J2ZUqFTa7m+iDV/50t+LKYXDu25 X-Received: by 2002:a17:902:da83:b0:1e4:55d8:e5f1 with SMTP id j3-20020a170902da8300b001e455d8e5f1mr5159049plx.5.1713565445006; Fri, 19 Apr 2024 15:24:05 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713565444; cv=pass; d=google.com; s=arc-20160816; b=whaN1BO3fSZ2PD/hUTdw55YswwK6jNYszoCyfXkxNt+BiHE/UObWzJqXiiVcbPkltD UWFNufFAJafVU8dTiY+rC+JXIVQkuCRavtxn7kmZIYMxkLED4ooqE4jHK1O7SDaZlzs9 TliQCG4X7Jd8PmtBZXnZA02YlkuTyS6+UluZX0gLi4JJX+PMNTon9yb8hMUToGoog70W 7DfdGgOLhZZ0d7puzE6HS0lPWfv4Vz0AzUqRLOv8k1SVVLglfznp2LeMOjSV5BRnf6lI dXBqRthhkt2BkpNqnpWG7zwWGaVhMQfUJfzyGAal4aqt0/PrQdDAjNjLfcdDhCk/z/j2 Xp7Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:dkim-signature:date; bh=mthBWOOhcNSWoMZhMTAfzR7XGep2Qks53Rpg12wvEhs=; fh=cm6dzYxznhhTOkT8xGgT0Ubf6eACCz3yDanb0PxyH1U=; b=dDd0UYUDfI/EMwucRis322tpmJqkVP9lKZ2fFHAOKJtyMMQmkJEWhahxFin45aNZBw BBB2lPQvEHCX389WyEpaLv3e8USDwAQmIqpG+ReS9P0wWNhB5wszu2eWWG6XIyp4qRDp MR2hPXEMm9wdNiHmhKgu9s7WohfgMaY1M7lFSHJVY7ItCovGt20jvdSH6ZZCDCHJS/iX dzQFoiYyS1FUkaMP6RDRTzgVp9yCM8wWHrV8+fZuPX0fcil10bHwcJN3gthzFqAnDEI7 eXpCqBzfFEMiu24Yv5fWh8r80ure5d+VF3YRiXyc/sGSAHTa+tmo1AWJfZeV5I9AhX/8 IxVg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=P8isnNkf; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-152000-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-152000-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id c7-20020a170902724700b001e3fadbd18esi3696842pll.388.2024.04.19.15.24.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Apr 2024 15:24:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-152000-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=P8isnNkf; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-152000-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-152000-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 9964F28209D for ; Fri, 19 Apr 2024 22:24:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C646A13D2B1; Fri, 19 Apr 2024 22:23:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="P8isnNkf" Received: from out-172.mta1.migadu.com (out-172.mta1.migadu.com [95.215.58.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 69A1D13D292 for ; Fri, 19 Apr 2024 22:23:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713565436; cv=none; b=SC0Zeh53qCIC475TmvnGehxe1soAqE/6G+4KvjY3Y3wPwAGKeTV71nuWjX6kictq2KC4Wc5jpmddW8emsXL/9tBikNudl4lRH62hSyVa8fppZld1uGwuS4TWzbAEEGz0Hq9jDSpQ1FbwaIzExIkbTV8IOnJId0AQNKSrR8Ad/Jg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713565436; c=relaxed/simple; bh=VD6QFxX1Xd3DNVIOsaev//o7h4mZlv5eWXjCnxaWhik=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rsi+FGgJkE9C03Yx1QJ628FHssX//QOEHsMGcvI1EzYBGk2AyFG7zgZ2qaQLT0+B+OKpvjWKbewBNzdoHhpx+aCZAShhZKb33YEJKJR5QO/ES7ubzCRctdBJL3zJ/CsUZvNM0HlVVRNjWb2WKO0rUW3lKf5GsY3YwUe/Ldz9qfs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=P8isnNkf; arc=none smtp.client-ip=95.215.58.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Date: Fri, 19 Apr 2024 22:23:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1713565432; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mthBWOOhcNSWoMZhMTAfzR7XGep2Qks53Rpg12wvEhs=; b=P8isnNkfBYXWB0pGZ4e76KozKbuIPo6rHG7Ox+d9b31tlskAlwzX5Fiy922x3848sQHdds 2boqaE4bF1mMbPeod2X267+67KV2A02qKBDa6v3fbd7lZbgPblznjJvZe8hzyomSxDd6nH 88u9gjkSLzKAR6O3WgIDpbW6x4ZMNao= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: James Houghton Cc: David Matlack , Andrew Morton , Paolo Bonzini , Yu Zhao , Marc Zyngier , Sean Christopherson , Jonathan Corbet , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Shaoqin Huang , Gavin Shan , Ricardo Koller , Raghavendra Rao Ananta , Ryan Roberts , David Rientjes , Axel Rasmussen , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH v3 0/7] mm/kvm: Improve parallelism for access bit harvesting Message-ID: References: <20240401232946.1837665-1-jthoughton@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT On Fri, Apr 19, 2024 at 01:57:03PM -0700, James Houghton wrote: > On Fri, Apr 12, 2024 at 11:41 AM David Matlack wrote: > > > > On 2024-04-01 11:29 PM, James Houghton wrote: > > > This patchset adds a fast path in KVM to test and clear access bits on > > > sptes without taking the mmu_lock. It also adds support for using a > > > bitmap to (1) test the access bits for many sptes in a single call to > > > mmu_notifier_test_young, and to (2) clear the access bits for many ptes > > > in a single call to mmu_notifier_clear_young. > > > > How much improvement would we get if we _just_ made test/clear_young > > lockless on x86 and hold the read-lock on arm64? And then how much > > benefit does the bitmap look-around add on top of that? Thanks David for providing the suggestion. > I don't have these results right now. For the next version I will (1) > separate the series into the locking change and the bitmap change, and > I will (2) have performance data for each change separately. It is > conceivable that the bitmap change should just be considered as a > completely separate patchset. That'd be great. Having the performance numbers will make it even more compelling, but I'd be tempted to go for the lock improvement just because it doesn't add any new complexity and leverages existing patterns in the architectures that people seem to want improvements for. The bitmap interface, OTOH, is rather complex. At least the current implementation breaks some of the isolation we have between the MMU code and the page table walker library on arm64, which I'm not ecstatic about. It _could_ be justified by a massive performance uplift over locking, but it'd have to be a sizable win. -- Thanks, Oliver