linux-kernel - Re: [PATCH RFC 0/6] mm: THP-agnostic refactor on huge mappings

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: <4d12ae9a-de08-425d-8ee1-5b55e7e48254@cs-soprasteria.com>
Date: Thu, 22 Aug 2024 17:08:42 +0000
From: LEROY Christophe <christophe.leroy2@...soprasteria.com>
To: Peter Xu <peterx@...hat.com>, David Hildenbrand <david@...hat.com>, Andrew
 Morton <akpm@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, Vlastimil Babka <vbabka@...e.cz>,
	Oscar Salvador <osalvador@...e.de>, "linux-s390@...r.kernel.org"
	<linux-s390@...r.kernel.org>, Matthew Wilcox <willy@...radead.org>, Dan
 Williams <dan.j.williams@...el.com>, Michal Hocko <mhocko@...nel.org>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>, Alex Williamson
	<alex.williamson@...hat.com>, Jason Gunthorpe <jgg@...dia.com>,
	"x86@...nel.org" <x86@...nel.org>, Alistair Popple <apopple@...dia.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, Ryan Roberts <ryan.roberts@....com>,
	Hugh Dickins <hughd@...gle.com>, Axel Rasmussen <axelrasmussen@...gle.com>
Subject: Re: [PATCH RFC 0/6] mm: THP-agnostic refactor on huge mappings



Le 23/07/2024 à 23:04, Peter Xu a écrit :
>>
>>>
>>> Nornally I don't see this as much of a "code churn" category, because it
>>> doesn't changes the code itself but only move things.  I personally also
>>> prefer without code churns, but only in the case where there'll be tiny
>>> little functional changes here and there without real benefit.
>>>
>>> It's pretty unavoidable to me when one file grows too large and we'll need
>>> to split, and in this case git doesn't have a good way to track such
>>> movement..
>>
>> Yes, that's what I mean.
>>
>> I've been recently thinking if we should pursue a different direction:
>>
>> Just as we recently relocated most follow_huge_* stuff into gup.c, likely we
>> should rather look into moving copy_huge_pmd, change_huge_pmd, copy_huge_pmd
>> ... into the files where they logically belong to.
>>
>> In madvise.c, we've been doing that in some places already: For
>> madvise_cold_or_pageout_pte_range() we inline the code, but not for
>> madvise_free_huge_pmd().
>>
>> pmd_trans_huge() would already compile to a NOP without
>> CONFIG_TRANSPARENT_HUGEPAGE, but to make that code avoid most
>> CONFIG_TRANSPARENT_HUGEPAGE, we'd need a couple more function stubs to make
>> the compiler happy while still being able to compile that code out when not
>> required.
> 
> Right, I had a patch does exactly that, where it's called pmd_is_leaf(),
> for example, but taking CONFIG_* into account.
> 
> I remember I had some issue with that, e.g. I used to see pmd_trans_huge()
> (when !THP) can optimize some path but pmd_is_leaf() didn't do the same job
> even if all configs were off.  But that's another story and I didn't yet
> dig deeper.  Could be something small but overlooked.

When I prepared series 
https://patchwork.kernel.org/project/linux-mm/list/?series=871008 , I 
detected that some architectures define some pXd_leaf() for levels they 
don't support, that's the reason why Andrew had to drop v2 at the last 
minute.

And that's maybe the reason why some of the code you expect to get 
folded-off remains.

Since then I sent v3 that fixes that. Don't know if Andrew is planning 
to take it.

Christophe