On Sun, Sep 1, 2024 at 10:09 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, 1 Sep 2024 21:41:27 -0700 Suren Baghdasaryan <surenb@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/#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? >
