From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: SeongJae Park <sj@kernel.org>
Cc: 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 19:59:47 +0530 [thread overview]
Message-ID: <87fsb1g23o.fsf@linux.ibm.com> (raw)
In-Reply-To: <20230217164211.59619-1-sj@kernel.org>
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 will look at DAMON and see if that is the best framework for things
like this.
-aneesh
next prev parent reply other threads:[~2023-02-19 14:30 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 [this message]
2023-02-19 20:31 ` SeongJae Park
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=87fsb1g23o.fsf@linux.ibm.com \
--to=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=sj@kernel.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.