linux-kernel - Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags

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: <CAJuCfpGT8_t04Va94bZj2dBo8EhbX2rvVCdN6Jokfk1rjedV_Q@mail.gmail.com>
Date: Mon, 14 Oct 2024 19:03:10 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: John Hubbard <jhubbard@...dia.com>, Yosry Ahmed <yosryahmed@...gle.com>, 
	akpm@...ux-foundation.org, kent.overstreet@...ux.dev, corbet@....net, 
	arnd@...db.de, mcgrof@...nel.org, rppt@...nel.org, paulmck@...nel.org, 
	thuth@...hat.com, tglx@...utronix.de, bp@...en8.de, 
	xiongwei.song@...driver.com, ardb@...nel.org, david@...hat.com, 
	vbabka@...e.cz, mhocko@...e.com, hannes@...xchg.org, roman.gushchin@...ux.dev, 
	dave@...olabs.net, liam.howlett@...cle.com, pasha.tatashin@...een.com, 
	souravpanda@...gle.com, keescook@...omium.org, dennis@...nel.org, 
	yuzhao@...gle.com, vvvvvv@...gle.com, rostedt@...dmis.org, 
	iamjoonsoo.kim@....com, rientjes@...gle.com, minchan@...gle.com, 
	kaleshsingh@...gle.com, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, linux-mm@...ck.org, 
	linux-modules@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag
 refs in page flags

On Mon, Oct 14, 2024 at 6:40 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Mon, Oct 14, 2024 at 05:03:32PM -0700, John Hubbard wrote:
> > > > Or better yet, *always* fall back to page_ext, thus leaving the
> > > > scarce and valuable page flags available for other features?
> > > >
> > > > Sorry Suren, to keep coming back to this suggestion, I know
> > > > I'm driving you crazy here! But I just keep thinking it through
> > > > and failing to see why this feature deserves to consume so
> > > > many page flags.
> > >
> > > I think we already always use page_ext today. My understanding is that
> > > the purpose of this series is to give the option to avoid using
> > > page_ext if there are enough unused page flags anyway, which reduces
> > > memory waste and improves performance.
> > >
> > > My question is just why not have that be the default behavior with a
> > > config option, use page flags if there are enough unused bits,
> > > otherwise use page_ext.
> >
> > I agree that if you're going to implement this feature at all, then
> > keying off of CONFIG_MEM_ALLOC_PROFILING seems sufficient, and no
> > need to add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS on top of that.
>
> Maybe the right idea is to use all the bits which are unused in this
> configuration for the first N callsites, then use page_ext for all the
> ones larger than N.  It doesn't save any memory, but it does have the
> performance improvement.

Thanks for the idea! This would be more complicated and likely would
require additional branching instructions in the allocation path. I'll
think more about details but would prefer to get the simple solution
first before adding more complexity.