On 10/14/24 4:56 PM, Yosry Ahmed wrote:
On Mon, Oct 14, 2024 at 4:53 PM John Hubbard <jhubbard@xxxxxxxxxx> wrote:
On 10/14/24 4:48 PM, Yosry Ahmed wrote:
On Mon, Oct 14, 2024 at 1:37 PM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
Add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to store allocation tag
references directly in the page flags. This eliminates memory
overhead caused by page_ext and results in better performance
for page allocations.
If the number of available page flag bits is insufficient to
address all kernel allocations, profiling falls back to using
page extensions with an appropriate warning to disable this
config.
If dynamically loaded modules add enough tags that they can't
be addressed anymore with available page flag bits, memory
profiling gets disabled and a warning is issued.
Just curious, why do we need a config option? If there are enough bits
in page flags, why not use them automatically or fallback to page_ext
otherwise?
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.
thanks,
--
John Hubbard
