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: <CA8C72B6-E509-4FB0-BEAA-C4368EB7A419@fb.com>
Date:   Fri, 5 Aug 2022 19:51:32 +0000
From:   "Alex Zhu (Kernel)" <alexlzhu@...com>
To:     Matthew Wilcox <willy@...radead.org>
CC:     Rik van Riel <riel@...com>, 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


> 
> Ah!  So when that exists, this interface tells us "how well" we're doing.
> 

Yes, exactly. 
> 
> Yeah, debugfs seems like a better place.  And I'd love to see the shrinker
> code.  Before you mentioned that I was having all kinds of peculiar
> feelings about this code.  For example, suppose you have incredibly hot
> 256kB of data, but the other 1792kB of data are never touched ... that
> could cause us to do entirely the wrong thing and break up this THP.
> Having it as a shrinker makes sense because the hot 256kB will keep the
> THP from reaching the end of the list and being reclaimed.

Sounds good, I’ll move this to debugfs then. Will follow up with the shrinker code
in another patch. The shrinker relies on this scanning thread to figure out which
THPs to reclaim. 

What are your thoughts regarding integrating this with DAMON?