From: SeongJae Park <sj@kernel.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: SeongJae Park <sj@kernel.org>,
lsf-pc@lists.linux-foundation.org, Linux MM <linux-mm@kvack.org>,
Yu Zhao <yuzhao@google.com>, Dave Hansen <dave.hansen@intel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
damon@lists.linux.dev
Subject: Re: [LSF/MM/BPF TOPIC] Using hardware counters to determine hot/cold pages
Date: Sun, 19 Feb 2023 20:31:38 +0000 [thread overview]
Message-ID: <20230219203138.4873-1-sj@kernel.org> (raw)
In-Reply-To: <87fsb1g23o.fsf@linux.ibm.com>
Hi Aneesh,
On Sun, 19 Feb 2023 19:59:47 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
> SeongJae Park <sj@kernel.org> writes:
>
> > Hi Aneesh,
> >
> > On Fri, 17 Feb 2023 17:28:09 +0530 Aneesh Kumar K V <aneesh.kumar@linux.ibm.com> wrote:
> >
> >> PowerPC architecture (POWER10) supports a Hot/Cold page tracking
> >> facility that provides access counter and access affinity details at
> >> configurable page size granularity [1]. I have been looking at using
> >> this counter in different areas of the kernel such as
> >>
> >> 1) Page reclaim/demotion
> >> 2) THP utilization
> >> 3) Page promotion.
> >>
> >> I have done some MGLRU integration and would like to discuss the
> >> observation with the rest of the community. It is still not clear what
> >> are the best ways to integrate these hardware counters in the Linux
> >> kernel.
> >
> > Sounds very interesting. I think DAMON might be one another option, because it
> > is designed to be easy to extended with various source of access
> > information[1], and provides an abstraction layer for access temparature based
> > memory management[2], namely Data Access Monitoring-based Operation Schemes
> > (DAMOS).
> >
> >> Attached is the performance graph showing how the mongodb/ycsb
> >> benchmark performs when using hardware counters with MGLRU aging. An
> >> early RFC version of the code can be found at
> >> https://github.com/kvaneesh/linux/commit/b472e2c8080823bb4114c286270aea3e18ffe221
> >> . I also expect we can get some numbers w.r.t THP usage before the
> >> conference.
> >
> > I also have experimented a DAMON-based THP optimization[3], which shown
> > interesting results.
> >
> > Hope to discuss about this with you at LSF/MM. FYI, I also proposed an LSF/MM
> > topic for DAMON[4].
> >
> > [1] https://docs.kernel.org/mm/damon/design.html#configurable-layers
> > [2] https://docs.kernel.org/mm/damon/api.html#c.damos
> > [3] https://www.amazon.science/publications/daos-data-access-aware-operating-system
> > [4] https://lore.kernel.org/damon/20230214003328.55285-1-sj@kernel.org/
> >
> >
>
> The hardware counters that are supported in the case of POWER10 are
> based on physical addresses. The hardware facility will count the access
> across a physical address range and there is a counter for each page
> that gives the access count and also information about which node did
> access the page.
>
> I haven't spent much time studying DAMON so I might be wrong here. The
> reason I avoided using DAMON for the POC was because my goal was to
> evaluate how the hardware counters measured against the pte reference
> bit and I was not sure I could evaluate that using the DAMON action
> facility.
>
> I do agree that we could add a layer similar to DAMON_PADDR and expose
> the details to userspace. But I was not sure we can take action based on
> that. In most cases what I wanted was to move the coldest page in the
> Numa node to swap. So that is relative hotness rather than moving a page
> that got a hotness value less than 10 to swap even though we can figure
> out a way to make the latter similar to the former.
I think you could use DAMOS quota[1]. Under the quota, DAMOS prioritizes
regions based on the access pattern, and applies the action to higher-priority
regions, so you can do relative coldness-based reclamation, like DAMON_RECLAIM
does[2].
The interface might not very efficient for your specific case, though. I want
to know such cases and improve the interface or implement new features.
[1] https://docs.kernel.org/mm/damon/api.html#c.damos_quota
[2] https://docs.kernel.org/admin-guide/mm/damon/reclaim.html#quota-sz
>
>
> I will look at DAMON and see if that is the best framework for things
> like this.
Great, please feel free to reach out to me if you have any question or need
help.
Thanks,
SJ
>
> -aneesh
next prev parent reply other threads:[~2023-02-19 20:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 11:58 [LSF/MM/BPF TOPIC] Using hardware counters to determine hot/cold pages Aneesh Kumar K V
2023-02-17 16:42 ` SeongJae Park
2023-02-19 14:29 ` Aneesh Kumar K.V
2023-02-19 20:31 ` SeongJae Park [this message]
2023-02-17 16:53 ` Matthew Wilcox
2023-02-19 14:43 ` Aneesh Kumar K.V
2023-02-17 22:00 ` Yang Shi
2023-02-19 14:45 ` Aneesh Kumar K.V
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=20230219203138.4873-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=damon@lists.linux.dev \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=yuzhao@google.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.