linux-kernel - Re: [PATCH 6/7] mm: folio_may_be_cached() unless folio_test

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: <be8580b1-38cb-49a4-a916-95c9289059be@redhat.com>
Date: Mon, 8 Sep 2025 22:11:00 +0200
From: David Hildenbrand <david@...hat.com>
To: Hugh Dickins <hughd@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Will Deacon <will@...nel.org>,
 Shivank Garg <shivankg@....com>, Matthew Wilcox <willy@...radead.org>,
 Christoph Hellwig <hch@...radead.org>, Keir Fraser <keirf@...gle.com>,
 Jason Gunthorpe <jgg@...pe.ca>, John Hubbard <jhubbard@...dia.com>,
 Frederick Mayle <fmayle@...gle.com>, Peter Xu <peterx@...hat.com>,
 "Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
 Johannes Weiner <hannes@...xchg.org>, Vlastimil Babka <vbabka@...e.cz>,
 Alexander Krabler <Alexander.Krabler@...a.com>, Ge Yang
 <yangge1116@....com>, Li Zhe <lizhe.67@...edance.com>,
 Chris Li <chrisl@...nel.org>, Yu Zhao <yuzhao@...gle.com>,
 Axel Rasmussen <axelrasmussen@...gle.com>, Yuanchu Xie <yuanchu@...gle.com>,
 Wei Xu <weixugc@...gle.com>, Konstantin Khlebnikov <koct9i@...il.com>,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 6/7] mm: folio_may_be_cached() unless folio_test_large()

On 08.09.25 22:04, Hugh Dickins wrote:
> On Mon, 8 Sep 2025, David Hildenbrand wrote:
>> On 08.09.25 13:19, Hugh Dickins wrote:
> ...
>>>
>>> (Settimg aside that I've never perceived those pagevecs/batches as a
>>> "cache"; but lru_cache_disable() gave us that terminology, and we've
>>> gone with the flow ever since.  lru_add_drain() would be better named
>>> lru_cache_drain() now, I've always got hung up on "adding a drain".)
>>
>> Yeah, the terminology is not that intuitive :)
>>
>> Not sure if using "batched" instead of "cached" might be clearer long-term?
>>
>>>
>>> "may be" rather than "maybe" was intentional: perhaps too subtle,
>>> but to a native speaker it neatly expresses both the "we can do this"
>>> and "might this have been done" cases.
>>
>> I would wish we could find something that also non-native speakers can
>> immediately understand ;)
>>
>> "may_get_lru_cached" / "may_get_lru_batched"?
>>
>> /me could not even phrase it in German properly
>>
>>>
>>> kernel-doc?  I don't think so, this is very much an mm-internal
>>> matter, and I don't care for the way kernel-doc forces us towards
>>> boilerplate ("@folio: The folio.") rather than helpful comment.
>>
>> So a comment that this is an internal helper might be nice. Or we just move it
>> straight to mm/internal.h ?
> 
> mm/internal.h, where we hide things (GFP_RECLAIM_MASK etc!) that belong
> elsewhere?  No thanks.

Yes, or other mm-internal helpers that actually belong there. Like 
folio_raw_mapping() or folio_nr_pages_mapped().

> 
> David, I think you're over-thinking this: I'm coming to regret not just
> going with your excellent folio_test_large() optimization, and let
> someone else mess around with the naming.

Please don't feel like I'm pushing to hard here. If you feel the current 
naming is fine and for some reason I don't completely understand it 
should not be in mm/internal.h, all good.

-- 
Cheers

David / dhildenb