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

[Usama Arif]

On 17/04/2025 17:00, Suren Baghdasaryan wrote:
> On Thu, Apr 17, 2025 at 8:47 AM Shakeel Butt <shakeel.butt@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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