linux-kernel - Re: [PATCH v11 00/15] khugepaged: mTHP support

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: <y6ljs2byyzxkxqqxaf37kx5lqpshv47ndejksen2ihrvhcwksc@4r6f4sdtjd3g>
Date: Fri, 12 Sep 2025 16:44:17 +0100
From: Kiryl Shutsemau <kas@...nel.org>
To: Pedro Falcato <pfalcato@...e.de>
Cc: David Hildenbrand <david@...hat.com>,
 	Johannes Weiner <hannes@...xchg.org>, Nico Pache <npache@...hat.com>,
 linux-mm@...ck.org, 	linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 	ziy@...dia.com, baolin.wang@...ux.alibaba.com,
 lorenzo.stoakes@...cle.com, 	Liam.Howlett@...cle.com,
 ryan.roberts@....com, dev.jain@....com, corbet@....net,
 	rostedt@...dmis.org, mhiramat@...nel.org,
 mathieu.desnoyers@...icios.com, 	akpm@...ux-foundation.org,
 baohua@...nel.org, willy@...radead.org, peterx@...hat.com,
 	wangkefeng.wang@...wei.com, usamaarif642@...il.com,
 sunnanyong@...wei.com, 	vishal.moola@...il.com,
 thomas.hellstrom@...ux.intel.com, yang@...amperecomputing.com,
 	aarcange@...hat.com, raquini@...hat.com, anshuman.khandual@....com,
 	catalin.marinas@....com, tiwai@...e.de, will@...nel.org,
 dave.hansen@...ux.intel.com, 	jack@...e.cz, cl@...two.org,
 jglisse@...gle.com, surenb@...gle.com, 	zokeefe@...gle.com,
 rientjes@...gle.com, mhocko@...e.com, rdunlap@...radead.org,
 	hughd@...gle.com, richard.weiyang@...il.com, lance.yang@...ux.dev,
 vbabka@...e.cz, 	rppt@...nel.org, jannh@...gle.com
Subject: Re: [PATCH v11 00/15] khugepaged: mTHP support

On Fri, Sep 12, 2025 at 04:39:02PM +0100, Kiryl Shutsemau wrote:
> > Shower thought: it might be in these cases especially where the FreeBSD
> > reservation system comes in handy - best effort allocating a THP, but not
> > actually mapping it as such until you really _know_ it is hot - and until
> > then, memory reclaim can just break your THP down if it really needs to.
> 
> This is just silly. All downsides without benefit until maybe later. And
> for short-lived processes the "later" never comes.

The right way out is to get better info on access pattern from hardware.
For instance, if we move access bit out of page table entry and make it
independent of the actually mapping size that would give us much better
view on what actually is going on.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov