Re: [PATCH] alloc_tag: introduce Kconfig option for default compressed profiling

[Usama Arif <usamaarif642@gmail.com>]

On 17/04/2025 18:50, Usama Arif wrote:
> 
> 
> On 17/04/2025 17:00, Suren Baghdasaryan wrote:
>> On Thu, Apr 17, 2025 at 8:47 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>>>
>>> On Wed, Apr 16, 2025 at 05:11:11PM -0700, Suren Baghdasaryan wrote:
>>>> On Wed, Apr 16, 2025 at 2:41 PM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>>>>>
>>>>> On Wed, Apr 16, 2025 at 02:08:31PM -0700, Suren Baghdasaryan wrote:
>>>>>> On Wed, Apr 16, 2025 at 11:06 AM Usama Arif <usamaarif642@gmail.com> wrote:
>>>>>>>
>>>>>>> With this Kconfig option enabled, the kernel stores allocation tag references
>>>>>>> in the page flags by default.
>>>>>>>
>>>>>>> There are 2 reasons to introduce this:
>>>>>>> - As mentioned in [1], compressed tags dont have system memory overhead
>>>>>>> and much lower performance overhead. It would be preferrable to have this as
>>>>>>> the default option, and to be able to switch it at compile time. Another
>>>>>>> option is to just declare the static key as true by default?
>>>>>>> - As compressed option is the best one, it doesn't make sense to have to
>>>>>>> change both defconfig and command line options to enable memory
>>>>>>> allocation profiling. Changing commandline across a large number of services
>>>>>>> can result in signifcant work, which shouldn't be needed if the kernel
>>>>>>> defconfig needs to be changed anyways.
>>>>>>
>>>>>> The reason tag compression is not the default option is because it
>>>>>> works only if there are enough free bits in the page flags to store a
>>>>>> tag index. If you configure it to use page flags and your build does
>>>>>> not have enough free bits, the profiling will be disabled (see
>>>>>> alloc_tag_sec_init()).
>>>>>
>>>>> Is it possible to fail the build in that case i.e. check the page flags
>>>>> availability at build time?
>>>>
>>>> The difficulty is finding out the number of allocation tags in the
>>>> kernel before it gets built. Maybe there is a way to add an additional
>>>> post-build stage to run that check.
>>>
>>> Yeah that would be good to have.
>>>
>>>> But even then making this option
>>>> default and causing build failures does not seem like a good idea to
>>>> me but maybe I'm being too cautious?
>>>
>>> Oh my question was orthogonal to the patch. Basically some users may
>>> want build time guarantee for this and they can enable such
>>> build-failing opt-in config/check.
>>
>> Yes, that would require the post-build step to check the number of
>> tags vs the number of available page flag bits. I'll add it to my TODO
>> list but it won't be at the top, sorry :) Volunteers to help with that
>> would be highly appreciated.
> 
> Hi Suren,
> 
> A question orthogonal to the patch, the defconfig entry is defined as below:
> 
> config MEM_ALLOC_PROFILING
> 	bool "Enable memory allocation profiling"
> 	default n
> 	depends on MMU
> 	depends on PROC_FS
> 	depends on !DEBUG_FORCE_WEAK_PER_CPU
> 	select CODE_TAGGING
> 	select PAGE_EXTENSION
> 	select SLAB_OBJ_EXT
> 
> i.e. we select PAGE_EXTENSION even if we use compressed profiling and use page flags
> instead of page extension. Which means the 0.2% (8 bytes per struct page) memory overhead
> will still exist even when we dont need it?
> 
> Should we have some defconfig option (happy with any other way) that only allows compressed
> profiling (otherwise nothing), so that we don't have the dependency on page extension
> and thus not have the overhead if we only plan to use compressed profiling?
> 
> Thanks


Johannes pointed out the .need function of page_alloc_tagging_ops, i.e. need_page_alloc_tagging,
so page extensions wouldn't be enabled and hopefully there is no memory overhead when
mem_profiling_compressed is true. Let me know if my understanding is wrong.
And sorry for the noise!