From: Marc Zyngier <maz@kernel.org>
To: Yicong Yang <yangyicong@huawei.com>
Cc: <yangyicong@hisilicon.com>, <catalin.marinas@arm.com>,
<will@kernel.org>, <mark.rutland@arm.com>,
<linux-arm-kernel@lists.infradead.org>, <oliver.upton@linux.dev>,
<broonie@kernel.org>, <ryan.roberts@arm.com>,
<linuxarm@huawei.com>, <jonathan.cameron@huawei.com>,
<shameerali.kolothum.thodi@huawei.com>,
<prime.zeng@hisilicon.com>, <xuwei5@huawei.com>,
<wangkefeng.wang@huawei.com>
Subject: Re: [PATCH 0/2] Support Armv8.9/v9.4 FEAT_HAFT
Date: Tue, 06 Aug 2024 09:06:03 +0100 [thread overview]
Message-ID: <86jzgu2hzo.wl-maz@kernel.org> (raw)
In-Reply-To: <c7dd1eb4-4ac7-7900-de86-a4139409e20a@huawei.com>
On Tue, 06 Aug 2024 04:43:52 +0100,
Yicong Yang <yangyicong@huawei.com> wrote:
>
> On 2024/8/2 18:40, Marc Zyngier wrote:
> > On Fri, 02 Aug 2024 10:34:56 +0100,
> > Yicong Yang <yangyicong@huawei.com> wrote:
> >>
> >> From: Yicong Yang <yangyicong@hisilicon.com>
> >>
> >> This series adds basic support for FEAT_HAFT introduced in Armv8.9/v9.4
> >> and enable ARCH_HAS_NONLEAF_PMD_YOUNG. The latter will be used in
> >> lru-gen aging. Tested with lru-gen in below steps:
> >> 1. Generate a 1GiB workingset by `stress-ng --vm 1`. Then hang the task to
> >> stop accessing the memory. (AF bit won't be updated)
> >> 2. try to age the memory by /sys/kernel/debug/lru_gen
> >>
> >> Run above steps with LRU_GEN_NONLEAF_YOUNG(0x4) and not respectively
> >> (switching by /sys/kernel/mm/lru_gen/enabled). LRU_GEN_NONLEAF_YOUNG
> >> will clear and test the PMD AF bit on page walking for aging,
> >> otherwise will clear and test the PTE AF bit for aging. In this case
> >> LRU_GEN_NONLEAF_YOUNG will improve the efficiency of page scanning
> >> since pages won't be accessed and we don't need to scan each PTE.
> >
> > Improve by how much? Can you please publish numbers that demonstrate
> > the effect of this feature?
> >
>
> With LRU_GEN_NONLEAF_YOUNG ~40% time saved for 1GiB memory observed on our
> emulated platform.
This certainly looks impressive, but it is a very ad-hoc benchmark,
and emulation numbers don't necessarily result in similar improvement
on actual HW.
How does this translate for a more realistic/useful workload? Even
numbers obtained on another architecture would be useful.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-08-06 8:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-02 9:34 [PATCH 0/2] Support Armv8.9/v9.4 FEAT_HAFT Yicong Yang
2024-08-02 9:34 ` [PATCH 1/2] arm64: Add support for FEAT_HAFT Yicong Yang
2024-08-02 10:37 ` Marc Zyngier
2024-08-06 3:09 ` Yicong Yang
2024-08-06 7:57 ` Marc Zyngier
2024-08-06 13:11 ` Yicong Yang
2024-08-02 9:34 ` [PATCH 2/2] arm64: Enable ARCH_HAS_NONLEAF_PMD_YOUNG Yicong Yang
2024-08-02 10:40 ` [PATCH 0/2] Support Armv8.9/v9.4 FEAT_HAFT Marc Zyngier
2024-08-06 3:43 ` Yicong Yang
2024-08-06 8:06 ` Marc Zyngier [this message]
2024-08-06 13:35 ` Yicong Yang
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=86jzgu2hzo.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=oliver.upton@linux.dev \
--cc=prime.zeng@hisilicon.com \
--cc=ryan.roberts@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=xuwei5@huawei.com \
--cc=yangyicong@hisilicon.com \
--cc=yangyicong@huawei.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.