linux-kernel - Re: [PATCH 00/20] Add support for shared PTEs across processes

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: <Z5l9XpSntxyxMGKj@casper.infradead.org>
Date: Wed, 29 Jan 2025 00:59:10 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Anthony Yznaga <anthony.yznaga@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, markhemm@...glemail.com,
	viro@...iv.linux.org.uk, david@...hat.com, khalid@...nel.org,
	jthoughton@...gle.com, corbet@....net, dave.hansen@...el.com,
	kirill@...temov.name, luto@...nel.org, brauner@...nel.org,
	arnd@...db.de, ebiederm@...ssion.com, catalin.marinas@....com,
	mingo@...hat.com, peterz@...radead.org, liam.howlett@...cle.com,
	lorenzo.stoakes@...cle.com, vbabka@...e.cz, jannh@...gle.com,
	hannes@...xchg.org, mhocko@...nel.org, roman.gushchin@...ux.dev,
	shakeel.butt@...ux.dev, muchun.song@...ux.dev, tglx@...utronix.de,
	cgroups@...r.kernel.org, x86@...nel.org, linux-doc@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, mhiramat@...nel.org, rostedt@...dmis.org,
	vasily.averin@...ux.dev, xhao@...ux.alibaba.com, pcc@...gle.com,
	neilb@...e.de, maz@...nel.org
Subject: Re: [PATCH 00/20] Add support for shared PTEs across processes

On Tue, Jan 28, 2025 at 04:25:22PM -0800, Anthony Yznaga wrote:
> 
> On 1/28/25 4:11 PM, Andrew Morton wrote:
> > On Fri, 24 Jan 2025 15:54:34 -0800 Anthony Yznaga <anthony.yznaga@...cle.com> wrote:
> > 
> > > Some of the field deployments commonly see memory pages shared
> > > across 1000s of processes. On x86_64, each page requires a PTE that
> > > is 8 bytes long which is very small compared to the 4K page
> > > size.
> > Dumb question: why aren't these applications using huge pages?
> > 
> They often are using hugetlbfs but would also benefit from having page
> tables shared for other kinds of memory such as shmem, tmpfs or dax.

... and the implementation of PMD sharing in hugetlbfs is horrible.  In
addition to inverting the locking order (see gigantic comment in rmap.c),
the semantics aren't what the Oracle DB wants, and it's inefficient.

So when we were looking at implementing page table sharing for DAX, we
examined _and rejected_ porting the hugetlbfs approach.  We've discussed
this extensively at the last three LSFMM sessions where mshare has been
a topic, and in previous submissions of mshare.  So seeing the question
being asked yet again is disheartening.