linux-kernel - Re: [PATCH v9 mm-new 03/11] mm: thp: add support for BPF based THP order selection

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] [day] [month] [year] [list]

Message-ID: <CALOAHbDqP3fH2_4r+5_9D46qrFiaRYHYGzW7M-fwwt4_qW9Npw@mail.gmail.com>
Date: Mon, 13 Oct 2025 21:07:27 +0800
From: Yafang Shao <laoar.shao@...il.com>
To: David Hildenbrand <david@...hat.com>
Cc: Tejun Heo <tj@...nel.org>, Michal Hocko <mhocko@...e.com>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Zi Yan <ziy@...dia.com>, 
	Alexei Starovoitov <alexei.starovoitov@...il.com>, Johannes Weiner <hannes@...xchg.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, baolin.wang@...ux.alibaba.com, 
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Liam Howlett <Liam.Howlett@...cle.com>, npache@...hat.com, 
	ryan.roberts@....com, dev.jain@....com, usamaarif642@...il.com, 
	gutierrez.asier@...wei-partners.com, Matthew Wilcox <willy@...radead.org>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Amery Hung <ameryhung@...il.com>, 
	David Rientjes <rientjes@...gle.com>, Jonathan Corbet <corbet@....net>, 21cnbao@...il.com, 
	Shakeel Butt <shakeel.butt@...ux.dev>, lance.yang@...ux.dev, 
	Randy Dunlap <rdunlap@...radead.org>, bpf <bpf@...r.kernel.org>, 
	linux-mm <linux-mm@...ck.org>, "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 mm-new 03/11] mm: thp: add support for BPF based THP
 order selection

On Mon, Oct 13, 2025 at 8:42 PM David Hildenbrand <david@...hat.com> wrote:
>
> >> I came to the same conclusion. At least it's a valid start.
> >>
> >> Maybe we would later want a global fallback BPF-THP prog if none was
> >> enabled for a specific MM.
> >
> > good idea. We can fallback to the global model when attaching pid 1.
> >
> >>
> >> But I would expect to start with a per MM way of doing it, it gives you
> >> way more flexibility in the long run.
> >
> > THP, such as shmem and file-backed THP, are shareable across multiple
> > processes and cgroups. If we allow different BPF-THP policies to be
> > applied to these shared resources, it could lead to policy
> > inconsistencies.
>
> Sure, but nothing new about that (e.g., VM_HUGEPAGE, VM_NOHUGEPAGE,
> PR_GET_THP_DISABLE).
>
> I'd expect that we focus on anon THP as the first step either way.
>
> Skimming over this series, anon memory seems to be the main focus.

Right, currently it is focusing on anon memory. In the next step it
will be extended to file-backed THP.

>
> > This would ultimately recreate a long-standing issue
> > in memcg, which still lacks a robust solution for this problem [0].
> >
> > This suggests that applying SCOPED policies to SHAREABLE memory may be
> > fundamentally flawed ;-)
>
> Yeah, shared memory is usually more tricky: see mempolicy handling for
> shmem. There, the policy is much rather glued to a file than to a process.

For shared THP we are planning to apply the THP policy based on vma->vm_file.

Consequently, the existing BPF-THP policies, which are scoped to a
process or cgroup, are incompatible with shared THP. This raises the
question of how to effectively scope policies for shared memory. While
one option is to key the policy to the file structure, this may not be
ideal as it could lead to considerable implementation and maintenance
challenges...

-- 
Regards
Yafang