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 8A889CD128A for ; Tue, 9 Apr 2024 18:32:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 11B8F6B0085; Tue, 9 Apr 2024 14:32:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CC956B0087; Tue, 9 Apr 2024 14:32:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED5BF6B0088; Tue, 9 Apr 2024 14:32:13 -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 CF2AF6B0085 for ; Tue, 9 Apr 2024 14:32:13 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 86EBE40445 for ; Tue, 9 Apr 2024 18:32:13 +0000 (UTC) X-FDA: 81990838146.18.55F4670 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf05.hostedemail.com (Postfix) with ESMTP id A91D0100019 for ; Tue, 9 Apr 2024 18:32:11 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=SlB+Kt3k; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of jthoughton@google.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712687531; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=j5abdwPMGcw7HwoxC4O5J3s+hF9tO/lLXB8776mOmRQ=; b=4C3xT0iJkp4F0wCR3RBOEOHkZeIkE2uYG9LMwUfhi8kPObpVdK8uF6VHIATPT9w5VQYx8w HbeV3cuWEp5PR78rsZAO1tRxuZ9+Ut6+H8hSQufrf8QAWKi/cJ7421wp0rmjrvj4GLDGj7 +tlrbtXGrUuVyPlwD2tweoB067jERe4= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=SlB+Kt3k; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of jthoughton@google.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712687531; a=rsa-sha256; cv=none; b=QwosJwMetMRN8cofyG238DgzpWV4WdJPsixLVs9PByXWOoCKYjksV8Itadr6V9VcRXeYGU XnIORjrjh6sy+8+6PRVgIoLmjg2bnyisB/flQOIHIw4QSExwilBmMhEvoRNvnbRJgZeEXO WzUmVaesN2b+PrZRwisiwaSNf/39Mpo= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1e062f3a47bso21125ad.1 for ; Tue, 09 Apr 2024 11:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712687530; x=1713292330; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=j5abdwPMGcw7HwoxC4O5J3s+hF9tO/lLXB8776mOmRQ=; b=SlB+Kt3kOTwY3OQWHJGA+SkOMCD2MDvAq1vKhi/oRlS3BGHuXML/1kl0pvR5rnpjUH 7iHKupEfIdCdbnhV+PrpHulg9EbkhsLOA7mal2Dow7iVYRTy9ZV9MU/QcwsD70f9gLce tclDvf0vu7P14qDSJzJ8Hjqmn8OkGTYGaPSRl+tDvCfk0D4c9NjVVckZYNrnlOjhFMXk 8Uzh00QypQyEJdV+/ua9sdhINwfHBTGzQYLIKQeJIFTL4iy3OhcyUpbnTSo5/Ka62PWO OkNCK30oVezCws5GqgQdPpUfWz64sXzwI/IcEFUGDk+4WGvXkSSMZYyfmmn/ad/JjpVN c5tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712687530; x=1713292330; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=j5abdwPMGcw7HwoxC4O5J3s+hF9tO/lLXB8776mOmRQ=; b=Sdim0Tq39ENlMOvc9z7vasvVN/8GvePoXZx2JXzyvT8LZBGz0u4T+gsL2UQJ1jyf44 WdH9I8VMCHLEolmXmWDzPZspZns19+t/YCnhGeFwK53RdWVXv6ZHZOCXU4l8NkabQIAh WrOUrlZnDeSKhUFELkt/NrHpblRMXIgvXeYFsoVQK1qig9FlRaiMh8oMSenxaEr6wjpM 6fx8+H0vylcHflgON+6dhqbtTy+EKdAniFyp2UIqnl5exodNmF+dvzoluQ7gGkIbb+Fk JGKjYbSgr0XFkQvOThDCsZ/hMj9kp4OpFzNAnkkSHM2LBSNvEs8nTKlT/78CZC3gAVW+ ycqA== X-Forwarded-Encrypted: i=1; AJvYcCUHgRrC7gwpwwTyT8JFB3fVusnU2WTw3FJPt/LFpqPW/AHPhVJ5dGmSpBLszpblqHG8vke0BfuomOZ1TY3utEdpsiE= X-Gm-Message-State: AOJu0YxfBMcK5e85e01cciFzPJhyJ7Yg1YGTzgS+gE1BN1zOPTHWfyrg odhZcqDnIz/peZqMBoDZW4sMz5FtXqntfEtfyqpqTS1XQKHD2ZsjPeRyiK9OzYKuHaoCB7jPj+O ws81pUW649PWX8ROy8CkIZj4MFSGAOHrMxXac X-Google-Smtp-Source: AGHT+IGasFNl4zWnhHzHdsfe5RR8e786OEjTNDXrnKxiWvA1Zc0Whu+C9yfBrzIuflmTKPt/f3PNAqmuUJdBFDt8Z5g= X-Received: by 2002:a17:902:d4c5:b0:1e3:dff3:2a3b with SMTP id o5-20020a170902d4c500b001e3dff32a3bmr11701plg.17.1712687530152; Tue, 09 Apr 2024 11:32:10 -0700 (PDT) MIME-Version: 1.0 References: <20240401232946.1837665-1-jthoughton@google.com> <20240401232946.1837665-2-jthoughton@google.com> In-Reply-To: From: James Houghton Date: Tue, 9 Apr 2024 11:31:32 -0700 Message-ID: Subject: Re: [PATCH v3 1/7] mm: Add a bitmap into mmu_notifier_{clear,test}_young To: David Hildenbrand Cc: Andrew Morton , Paolo Bonzini , Yu Zhao , David Matlack , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A91D0100019 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: zbc14tci6tz7fwsb9xey51zhfximg9bf X-HE-Tag: 1712687531-354666 X-HE-Meta: U2FsdGVkX1/ZPbiO2bZ5icw/Yf/TPXQ6zLJT7b6Onjn9+UMsJB9Xzl63HgpF0LGZJxMPqaXlv2Q+Fuv+sn8rf5oAe85FNPDkoG9bGPoMbVTOROV5Tbfvb14W8x/v5qE1nB8v36hSEZ4J/rSyZB2uU75uvQYGuo824fdTXITdDXwv9u58vImpM5Zm26H/N+ceWDoLuPLmeaE+VTtXco7Y7NmlPMt5aPj3ZU+wqIJckxZZYZi40X2jWBvd4/dkHndpuZiZG5y54hEl0/fPfc6Cehpnf/GY1eSigkw1BWdeeCBf1zL5NIwnC+tjL9/R9Rnp/U9Fx9/aJUwjjILWjKi3LxNBPjOhQqjT0Pgghbaqty3nrc5VR3AQmmSmMaj/NAHE/HNv3BWc1qJiw6Wt8obJX8FwnLG/nQ7xuahZUGLLu92Q0Qb65z7VVFaOTjPh/7rAX57oPCLBgWg1OcJhD3HdOCEXAHJmvHRaimDGFKoUmFHLJLE4bFF1cwh3Ep5ABzLXn3s1eAM/8y2ULJSSWL+j5gDb0zhIWkmOlVgYjO/HssuLqm++7IBnvLKUn2V/RUOBFwl61f/eSvLO8+xHG0jatbf8vtYZpZS1L0lU5YfvO9i8L1jobTMvrHpc1CjNL4/gn/w83ipVjT0XEwIbVW7ysYk5NSJ0jVWhyB6ix40y4LjS7FeTOrPpgYXV4bIvFioc0vnfFJZ+VBUsHWufx17KeknHFDZTcHuYw2iAWCvunRHDhXrrit0QQ60+wkqMZKGOYRCl/XsdDBtv0LVT8jMNYWoFb6SRqNTRh4vO0+5rsbjXkm7QfqSEJFeIaXTdFU7L0yvvEVQiHp78aX7zz9zGnyLXeUnHvT9blpc+Ubwce0jzphroBN4uncrDkJ2AHKkjNQfgJJHboyJryTDEIWjSskH5A4iq/89eHXVidP3eE2SYPJqla8Pk9A7h+c/fSt3pKqAT+3E8TJd3LU17y7A GB0P2dp2 0ITmSqg9quT+qKP4knh9GtRzWsxSWlWdGCGckOmnCtodWQDlVekVjHkEUEXC64EzsBSmyh1dba9WjSdtloQffESN0AgMPuNiMrUrjzBpiLbmPEo3Rd2cgJWB8E+UmXqdqZVShF/WdfEZvWmFRkIr0HBgm5KTjeKh2p42WuFqG1Ys+FaxWnSZxN85wO5zjankNq+2LBSs+0+PP9qzsGbyihMX2DiQtxRf3YHH8gh/s3hFFkpRD5iG5rT0pAOpDpOZdEEQTVMMuRCJNZL525D76SGS8DPrS8WvR7AWbxBJ0O1R4GaA= 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: Ah, I didn't see this in my inbox, sorry David! On Thu, Apr 4, 2024 at 11:52=E2=80=AFAM David Hildenbrand wrote: > > On 02.04.24 01:29, James Houghton wrote: > > 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) > > Especially this one really deserves some documentation :) Yes, will do. Something like MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE indicates that the passed-in bitmap either (1) does not accurately represent the age of the pages (in the case of test_young), or (2) was not able to be used to completely clear the age/access bit (in the case of clear_young). > > > +#define MMU_NOTIFIER_YOUNG_FAST (1 << 2) > > And that one as well. Something like Indicates that (1) passing a bitmap ({test,clear}_young_bitmap) would have been supported for this address range. The name MMU_NOTIFIER_YOUNG_FAST really comes from the fact that KVM is able to harvest the access bit "fast" (so for x86, locklessly, and for arm64, with the KVM MMU read lock), "fast" enough that using a bitmap to do look-around is probably a good idea. > > Likely best to briefly document all of them, and how they are > supposed to be used (return value for X). Right. Will do. > > > + > > struct mmu_notifier_ops { > > /* > > * Called either by mmu_notifier_unregister or when the mm is > > @@ -106,21 +110,36 @@ struct mmu_notifier_ops { > > * clear_young is a lightweight version of clear_flush_young. Lik= e the > > * latter, it is supposed to test-and-clear the young/accessed bi= tflag > > * in the secondary pte, but it may omit flushing the secondary t= lb. > > + * > > + * If @bitmap is given but is not supported, return > > + * MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE. > > + * > > + * If the walk is done "quickly" and there were young PTEs, > > + * MMU_NOTIFIER_YOUNG_FAST is returned. > > */ > > int (*clear_young)(struct mmu_notifier *subscription, > > struct mm_struct *mm, > > unsigned long start, > > - unsigned long end); > > + unsigned long end, > > + unsigned long *bitmap); > > > > /* > > * test_young is called to check the young/accessed bitflag in > > * the secondary pte. This is used to know if the page is > > * frequently used without actually clearing the flag or tearing > > * down the secondary mapping on the page. > > + * > > + * If @bitmap is given but is not supported, return > > + * MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE. > > + * > > + * If the walk is done "quickly" and there were young PTEs, > > + * MMU_NOTIFIER_YOUNG_FAST is returned. > > */ > > int (*test_young)(struct mmu_notifier *subscription, > > struct mm_struct *mm, > > - unsigned long address); > > + unsigned long start, > > + unsigned long end, > > + unsigned long *bitmap); > > What does "quickly" mean (why not use "fast")? What are the semantics, I > don't find any existing usage of that in this file. "fast" means fast enough such that using a bitmap to scan adjacent pages (e.g. with MGLRU) is likely to be beneficial. I'll write more in this comment. Perhaps I should just rename it to MMU_NOTIFIER_YOUNG_BITMAP_SUPPORTED and drop the whole "likely to be beneficial" thing -- that's for MGLRU/etc. to decide really. > > Further, what is MMU_NOTIFIER_YOUNG you introduce used for? MMU_NOTIFIER_YOUNG is the return value when the page was young, but we (1) didn't use a bitmap, and (2) the "fast" access bit harvesting wasn't possible. In this case we simply return 1, which is MMU_NOTIFIER_YOUNG. I'll make kvm_mmu_notifier_test_clear_young() properly return MMU_NOTIFIER_YOUNG instead of relying on the fact that it will be 1. Thanks David!