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]

Message-ID: <0b16dbac6444bfcdfbeb4df4280354839bfe1a8f.camel@fb.com>
Date:   Fri, 5 Aug 2022 19:04:30 +0000
From:   Rik van Riel <riel@...com>
To:     "Alex Zhu (Kernel)" <alexlzhu@...com>,
        "willy@...radead.org" <willy@...radead.org>
CC:     Kernel Team <Kernel-team@...com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3] mm: add thp_utilization metrics to
 /proc/thp_utilization

On Fri, 2022-08-05 at 19:50 +0100, Matthew Wilcox wrote:
> > 
> > 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?

Alex does have an (in kernel) shrinker that can reclaim
underutilized THPs in order to free memory.

This is a regular shrinker called from kswapd. I am not
sure a shrinker going through the DAMON infrastructure
would be any smaller, faster, or better. OTOH, DAMON
does allow for more flexible policy...

Getting some info on the effectiveness of the shrinker
seems useful, though. Could debugfs be a better place?
Should this be resubmitted together with the shrinker
code that makes this more useful?