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 34810C4345F for ; Fri, 12 Apr 2024 18:45:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HdLfB16EdoaQ5zxUoI9W/FKDAUS01jqDpKYUi50a2t0=; b=WuP6t2/VRAzjzD 1G9ATmj0WnVWb4n7IFxXpMaKH6RwOZV6P4JT1qT9X3KWolXAqFbzxRdxcybhj9o9fIDYBojBxMfPK QTeDneNRsvYRkVPbqHTVRIuD6/BKeWSMLXBBYY/t4eoyQZGmjgY0cqBJexON7RyWwYd9hZQyYxDBk EerWdcb/M+AAoAh/9TNq/3ZxT6mQXxBdnk93iEOfstIyDrtvePfHnPZzs9bexwYku2hxZRLMhBfIl 7BF5z/naoIK9Pqxym4DhDvfh/1LSq7dw5BVAcTEqzjCFerbuI56ooqPasMJUMU+cAZcMpqEqacI3i K5o3BaDOIjWSfH4Jl90g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rvLuC-00000000vWJ-3kLf; Fri, 12 Apr 2024 18:45:44 +0000 Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rvLu8-00000000vUv-3YDB for linux-arm-kernel@lists.infradead.org; Fri, 12 Apr 2024 18:45:42 +0000 Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-5ce2aada130so844684a12.1 for ; Fri, 12 Apr 2024 11:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712947539; x=1713552339; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ISLMFGOGyzbAhcth9c+vgcaA14m4ctbEbkD9TmYI1+8=; b=1oBwILpG11Z4o2RCvIV5Xpj7Pki8gp6spYc7cQV5v6oVOrctLbAm3pVgqqVm17x5aX fMPFyRrGhj/TBgsouSZv1HIo8HiSqQfOxKgz+7N2PzahkSW+TKUwi5mkpMy/pGvQ3xVh 041ospdv73royxAAYgVeI4xIFvz4lSovSKMIPZxo7JnGitAmtLvOM2uc33SrK65ozQz6 LyQM5R0drhhP9jwIFqRAP2k+8T1iui5tM98OYiIWuxwi4TeyqaMPgUWGoT156TFkfrej 8YyMUXfDOXjzvEZ9JWp2btXg1XwrgxYNR9hJ2BqY4fta3XBF9XNmT6ccgSk7+w3BG42f YZNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712947539; x=1713552339; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ISLMFGOGyzbAhcth9c+vgcaA14m4ctbEbkD9TmYI1+8=; b=JIYXIN4W8yHa3yuWXb18TwZuei+xaOIM71kTIvpsMhwvbsws0vq3LtqMKueYpcRBAW lU7AKyr+Q/9vn8igSzEkVhZhJjwBVR68QHcwb5stdKsOh1BbQyRIxWzQo2vRYe2wFMP5 hD24m4/pFJ98O2KvOELB3aONSU942d5QDfpVUGpd73hFIuFkkFkumm9hDkTCe1MKHv4D gzrYGEJgtyuzkkj7ivONGQW5d1WJySqixY8jkCBgtA2ogYgwo+H7N0t9od4/PfFMLlrp u9VSxGREudwKxuFgJQ0IRo5hez5vmkL/XJFES/P+IrDI5lBOUkZonOBFexASVxwza7gV YHDQ== X-Forwarded-Encrypted: i=1; AJvYcCVpOQMdp3Xm/5qiOmrMIhkQn1SVVHJVuvWBZ4vCLQxU4FzXnRqxseucyrANbFEDeLEFZivUp4lTN7mBmoY+nVoqZwpAxQ7quYEBlf6j4Gs1NYaAGIM= X-Gm-Message-State: AOJu0YxCsqtLjylks3m/CVLLjsiZpBo6xCsvrAW13uiWhEdGDKy6kDxs gqXKK09PxK/ViQra7tYidEsvvOf3AaWd4HTbNMkNrgYMTfHpsdgaU6E1e9Ft5w== X-Google-Smtp-Source: AGHT+IErdx6N/Za0LUKOOdr+VzWwjNC6bZuRp56Svh5aVZ0iXA0UlC0kIs2SDcy0//cfbrlbvHooqg== X-Received: by 2002:a17:90a:9af:b0:2a5:3e4e:29a0 with SMTP id 44-20020a17090a09af00b002a53e4e29a0mr3344779pjo.6.1712947538843; Fri, 12 Apr 2024 11:45:38 -0700 (PDT) Received: from google.com (210.73.125.34.bc.googleusercontent.com. [34.125.73.210]) by smtp.gmail.com with ESMTPSA id i20-20020a632214000000b005cd835182c5sm3009589pgi.79.2024.04.12.11.45.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Apr 2024 11:45:38 -0700 (PDT) Date: Fri, 12 Apr 2024 11:45:33 -0700 From: David Matlack To: James Houghton Cc: Andrew Morton , Paolo Bonzini , Yu Zhao , Marc Zyngier , Oliver Upton , 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 1/7] mm: Add a bitmap into mmu_notifier_{clear,test}_young Message-ID: References: <20240401232946.1837665-1-jthoughton@google.com> <20240401232946.1837665-2-jthoughton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240401232946.1837665-2-jthoughton@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240412_114540_915926_FBB97313 X-CRM114-Status: GOOD ( 30.75 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2024-04-01 11:29 PM, James Houghton wrote: > The bitmap is provided for secondary MMUs to use if they support it. For > test_young(), after it returns, the bitmap represents the pages that > were young in the interval [start, end). For clear_young, it represents > the pages that we wish the secondary MMU to clear the accessed/young bit > for. > > If a bitmap is not provided, the mmu_notifier_{test,clear}_young() API > should be unchanged except that if young PTEs are found and the > architecture supports passing in a bitmap, instead of returning 1, > MMU_NOTIFIER_YOUNG_FAST is returned. > > This allows MGLRU's look-around logic to work faster, resulting in a 4% > improvement in real workloads[1]. Also introduce MMU_NOTIFIER_YOUNG_FAST > to indicate to main mm that doing look-around is likely to be > beneficial. > > If the secondary MMU doesn't support the bitmap, it must return > an int that contains MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE. > > [1]: https://lore.kernel.org/all/20230609005935.42390-1-yuzhao@google.com/ > > Suggested-by: Yu Zhao > Signed-off-by: James Houghton > --- > include/linux/mmu_notifier.h | 93 +++++++++++++++++++++++++++++++++--- > include/trace/events/kvm.h | 13 +++-- > mm/mmu_notifier.c | 20 +++++--- > virt/kvm/kvm_main.c | 19 ++++++-- > 4 files changed, 123 insertions(+), 22 deletions(-) > > diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h > index f349e08a9dfe..daaa9db625d3 100644 > --- a/include/linux/mmu_notifier.h > +++ b/include/linux/mmu_notifier.h > @@ -61,6 +61,10 @@ enum mmu_notifier_event { > > #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0) > > +#define MMU_NOTIFIER_YOUNG (1 << 0) > +#define MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE (1 << 1) MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE appears to be unused by all callers of test/clear_young(). I would vote to remove it. > +#define MMU_NOTIFIER_YOUNG_FAST (1 << 2) Instead of MMU_NOTIFIER_YOUNG_FAST, how about MMU_NOTIFIER_YOUNG_LOOK_AROUND? i.e. The secondary MMU is returning saying it recommends doing a look-around and passing in a bitmap? That would avoid the whole "what does FAST really mean" confusion. > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index fb49c2a60200..ca4b1ef9dfc2 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -917,10 +917,15 @@ static int kvm_mmu_notifier_clear_flush_young(struct mmu_notifier *mn, > static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn, > struct mm_struct *mm, > unsigned long start, > - unsigned long end) > + unsigned long end, > + unsigned long *bitmap) > { > trace_kvm_age_hva(start, end); > > + /* We don't support bitmaps. Don't test or clear anything. */ > + if (bitmap) > + return MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE; Wouldn't it be a bug to get a bitmap here? The main MM is only suppost to pass in a bitmap if the secondary MMU returns MMU_NOTIFIER_YOUNG_FAST, which KVM does not do at this point. Put another way, this check seems unneccessary. > + > /* > * Even though we do not flush TLB, this will still adversely > * affect performance on pre-Haswell Intel EPT, where there is > @@ -939,11 +944,17 @@ static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn, > > static int kvm_mmu_notifier_test_young(struct mmu_notifier *mn, > struct mm_struct *mm, > - unsigned long address) > + unsigned long start, > + unsigned long end, > + unsigned long *bitmap) > { > - trace_kvm_test_age_hva(address); > + trace_kvm_test_age_hva(start, end); > + > + /* We don't support bitmaps. Don't test or clear anything. */ > + if (bitmap) > + return MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE; Same thing here. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel