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.
