From: Matthew Wilcox <willy@infradead.org>
To: alexlzhu@fb.com
Cc: linux-mm@kvack.org, kernel-team@fb.com,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH v3] mm: add thp_utilization metrics to /proc/thp_utilization
Date: Fri, 5 Aug 2022 19:50:24 +0100 [thread overview]
Message-ID: <Yu1mcD6Jp4fCVEMi@casper.infradead.org> (raw)
In-Reply-To: <20220805184016.2926168-1-alexlzhu@fb.com>
On Fri, Aug 05, 2022 at 11:40:16AM -0700, alexlzhu@fb.com wrote:
> THPs have historically been enabled on a per application basis due to
> performance increase or decrease depending on how the particular
> application uses physical memory. When THPs are heavily utilized,
> application performance improves due to fewer TLB cache misses.
> It has long been suspected that performance regressions when THP
> is enabled happens due to heavily underutilized anonymous THPs.
>
> Previously there was no way to track how much of a THP is
> actually being used. With this change, we seek to gain visibility
> into the utilization of THPs in order to make more intelligent
> decisions regarding paging.
>
> This change introduces a tool that scans through all of physical
> memory for anonymous THPs and groups them into buckets based
> on utilization. It also includes an interface under
> /proc/thp_utilization.
OK, so I understand why we want to do the scanning, but why do we want to
report it to userspace at all? And if we do, why do we want to do it in
this format? AFAIK, there's nothing userspace can do with the information
"93% of your THPs are underutilised". If there was something userspace
could do about it, wouldn't it need to know which ones?
Isn't the real solution here entirely in-kernel? This scanning thread
you've created should be the one splitting the THPs. And anyway, isn't
this exactly the kind of thing that DAMON was invented for?
next prev parent reply other threads:[~2022-08-05 18:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-05 18:40 alexlzhu
2022-08-05 18:50 ` Matthew Wilcox [this message]
2022-08-05 19:04 ` Rik van Riel
2022-08-05 19:24 ` Matthew Wilcox
2022-08-05 19:51 ` Alex Zhu (Kernel)
2022-08-08 17:55 ` Yang Shi
2022-08-08 18:35 ` Rik van Riel
2022-08-09 17:11 ` Yang Shi
2022-08-09 17:15 ` Alex Zhu (Kernel)
2022-08-09 23:35 ` Yu Zhao
2022-08-10 17:07 ` Yang Shi
2022-08-10 17:14 ` Alex Zhu (Kernel)
2022-08-10 17:54 ` Yu Zhao
2022-08-10 21:39 ` Alex Zhu (Kernel)
2022-08-10 21:56 ` Yu Zhao
2022-08-11 0:00 ` Alex Zhu (Kernel)
2022-08-11 1:15 ` Yu Zhao
2022-08-11 2:08 ` Alex Zhu (Kernel)
2022-08-11 19:20 ` Alex Zhu (Kernel)
2022-08-11 21:55 ` Yu Zhao
2022-08-11 22:12 ` Yang Shi
2022-08-11 22:59 ` Yu Zhao
2022-08-07 6:03 ` kernel test robot
2022-08-07 6:44 ` kernel test robot
2022-08-07 6:55 ` kernel test robot
2022-08-08 17:52 ` Yang Shi
2022-08-05 20:28 William Kucharski
2022-08-05 21:14 William Kucharski
2022-08-05 21:46 ` Alex Zhu (Kernel)
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=Yu1mcD6Jp4fCVEMi@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=alexlzhu@fb.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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