From: Yu Zhao <yuzhao@google.com>
To: Will Deacon <will@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, x86@kernel.org,
page-reclaim@google.com, holger@applied-asynchrony.com,
iam@valdikss.org.ru, Konstantin Kharlamov <hi-angel@yandex.ru>,
catalin.marinas@arm.com
Subject: Re: [PATCH v5 01/10] mm: x86, arm64: add arch_has_hw_pte_young()
Date: Thu, 11 Nov 2021 04:11:29 -0700 [thread overview]
Message-ID: <CAOUHufZriWxEaYNmQaOGF26Bxv-2qOwLFpK_NhmL-GDVLtFDJw@mail.gmail.com> (raw)
In-Reply-To: <20211111085907.GA5407@willie-the-truck>
On Thu, Nov 11, 2021 at 1:59 AM Will Deacon <will@kernel.org> wrote:
>
> On Wed, Nov 10, 2021 at 09:15:01PM -0700, Yu Zhao wrote:
> > Some architectures automatically set the accessed bit in PTEs, e.g.,
> > x86 and arm64 v8.2. On architectures that do not have this capability,
> > clearing the accessed bit in a PTE triggers a page fault following the
> > TLB miss of this PTE.
> >
> > Being aware of this capability can help make better decisions, i.e.,
> > whether to limit the size of each batch of PTEs and the burst of
> > batches when clearing the accessed bit.
> >
> > Signed-off-by: Yu Zhao <yuzhao@google.com>
> > Tested-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > ---
> > arch/arm64/include/asm/cpufeature.h | 5 +++++
> > arch/arm64/include/asm/pgtable.h | 13 ++++++++-----
> > arch/arm64/kernel/cpufeature.c | 10 ++++++++++
> > arch/arm64/tools/cpucaps | 1 +
> > arch/x86/include/asm/pgtable.h | 6 +++---
> > include/linux/pgtable.h | 13 +++++++++++++
> > mm/memory.c | 14 +-------------
> > 7 files changed, 41 insertions(+), 21 deletions(-)
>
> *Please* cc the maintainers on arch patches. I asked you that last time,
> too:
>
> https://lore.kernel.org/r/20210819091923.GA15467@willie-the-truck
>
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 6ec7036ef7e1..940615d33845 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -2157,6 +2157,16 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> > .matches = has_hw_dbm,
> > .cpu_enable = cpu_enable_hw_dbm,
> > },
> > + {
> > + .desc = "Hardware update of the Access flag",
> > + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> > + .capability = ARM64_HW_AF,
> > + .sys_reg = SYS_ID_AA64MMFR1_EL1,
> > + .sign = FTR_UNSIGNED,
> > + .field_pos = ID_AA64MMFR1_HADBS_SHIFT,
> > + .min_field_value = 1,
> > + .matches = has_cpuid_feature,
> > + },
>
> As before, please don't make this a system feature as it will prohibit
> onlining of late CPUs with mismatched access flag support and I really
> don't see that being necessary.
>
> You should just be able to use arch_faults_on_old_pte() as-is.
Well, I did explain why last time and there weren't any pushbacks
after I listed my reasons:
1) there is no known hardware that does this, i.e., having mismatching
accessed bit capabilities.
2) there are no foreseeable benefits in supporting such a theoretical use case
There are many other opportunities ARM could explore, e.g., supporting
the accessed bit on non-leaf entries as x86 has been for decades.
Dwelling on this theoretical use case, IMO, is just a typical example
of overengineering.
But I do hear you -- as I mentioned last time, I don't have a problem
with doing it your way. Please touch on the two points I raised so
that I know where we stand. Otherwise I might again assume I've
convinced you to do it my way :)
Also why should I be able to use arch_faults_on_old_pte() as-is? This
implies we can make the following decisions based on the same
information.
1) set the accessed bit since the CPU we are running on won't do it for us
2) don't clear the accessed bit on too many entries since the CPU we
are running on will have a page fault upon seeing cleared accessed bit
on an entry
Are there conditions equivalent? Technically no, but it probably would
make no difference anyway.
My real problem with arch_faults_on_old_pte() is that it needs to be
called with preemption disabled. Again, IMO, a static branch for such
a common capability (from x86 perspective) is a no-brainer, because
there is zero return on investment in leaving the door open for
mismatching accessed bit capabilities.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-11 11:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 4:15 [PATCH v5 00/10] Multigenerational LRU Framework Yu Zhao
2021-11-11 4:15 ` [PATCH v5 01/10] mm: x86, arm64: add arch_has_hw_pte_young() Yu Zhao
2021-11-11 8:59 ` Will Deacon
2021-11-11 11:11 ` Yu Zhao [this message]
2021-11-11 4:15 ` [PATCH v5 02/10] mm: x86: add CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG Yu Zhao
2021-11-11 4:15 ` [PATCH v5 03/10] mm/vmscan.c: refactor shrink_node() Yu Zhao
2021-11-11 4:15 ` [PATCH v5 04/10] mm: multigenerational lru: groundwork Yu Zhao
2021-11-11 4:15 ` [PATCH v5 05/10] mm: multigenerational lru: mm_struct list Yu Zhao
2021-11-11 4:15 ` [PATCH v5 06/10] mm: multigenerational lru: aging Yu Zhao
2021-11-11 4:15 ` [PATCH v5 07/10] mm: multigenerational lru: eviction Yu Zhao
2021-11-11 4:15 ` [PATCH v5 08/10] mm: multigenerational lru: user interface Yu Zhao
2021-11-11 4:15 ` [PATCH v5 09/10] mm: multigenerational lru: Kconfig Yu Zhao
2021-11-11 4:15 ` [PATCH v5 10/10] mm: multigenerational lru: documentation Yu Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOUHufZriWxEaYNmQaOGF26Bxv-2qOwLFpK_NhmL-GDVLtFDJw@mail.gmail.com \
--to=yuzhao@google.com \
--cc=catalin.marinas@arm.com \
--cc=hi-angel@yandex.ru \
--cc=holger@applied-asynchrony.com \
--cc=iam@valdikss.org.ru \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=page-reclaim@google.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).