linux-kernel - Re: [PATCH v3] mm: add thp_utilization metrics to /proc/thp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 5 Aug 2022 19:50:24 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     alexlzhu@...com
Cc:     linux-mm@...ck.org, kernel-team@...com,
        linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [PATCH v3] mm: add thp_utilization metrics to
 /proc/thp_utilization

On Fri, Aug 05, 2022 at 11:40:16AM -0700, alexlzhu@...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?