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: <CAJuCfpHL04DyQn5WLz0GZ_zMYyg1b6UwKd_+8DSko843uSk7Ww@mail.gmail.com>
Date: Tue, 3 Sep 2024 18:07:28 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: 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, 
	willy@...radead.org, liam.howlett@...cle.com, pasha.tatashin@...een.com, 
	souravpanda@...gle.com, keescook@...omium.org, dennis@...nel.org, 
	jhubbard@...dia.com, 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 v2 5/6] alloc_tag: make page allocation tag reference size configurable

On Sun, Sep 1, 2024 at 10:09 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Sun,  1 Sep 2024 21:41:27 -0700 Suren Baghdasaryan <surenb@...gle.com> wrote:
>
> > Introduce CONFIG_PGALLOC_TAG_REF_BITS to control the size of the
> > page allocation tag references. When the size is configured to be
> > less than a direct pointer, the tags are searched using an index
> > stored as the tag reference.
> >
> > ...
> >
> > +config PGALLOC_TAG_REF_BITS
> > +     int "Number of bits for page allocation tag reference (10-64)"
> > +     range 10 64
> > +     default "64"
> > +     depends on MEM_ALLOC_PROFILING
> > +     help
> > +       Number of bits used to encode a page allocation tag reference.
> > +
> > +       Smaller number results in less memory overhead but limits the number of
> > +       allocations which can be tagged (including allocations from modules).
> > +
>
> In other words, "we have no idea what's best for you, you're on your
> own".
>
> I pity our poor users.
>
> Can we at least tell them what they should look at to determine whether
> whatever random number they chose was helpful or harmful?

At the end of my reply in
https://lore.kernel.org/all/CAJuCfpGNYgx0GW4suHRzmxVH28RGRnFBvFC6WO+F8BD4HDqxXA@mail.gmail.com/#t
I suggested using all unused page flags. That would simplify things
for the user at the expense of potentially using more memory than we
need. In practice 13 bits should be more than enough to cover all
kernel page allocations with enough headroom for page allocations
coming from loadable modules. I guess using 13 as the default would
cover most cases. In the unlikely case a specific system needs more
tags, the user can increase this value. It can also be set to 64 to
force direct references instead of indexing for better performance.
Would that approach be acceptable?

>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ