Re: [PATCH 01/26] mm: asi: Make some utility functions noinstr compatible

[Thomas Gleixner]

On Tue, Oct 29 2024 at 10:38, Junaid Shahid wrote:
> On 10/25/24 6:21 AM, Brendan Jackman wrote:
>>> I'd expect you either always inline the small functions - as you do for some
>>> aleady - or mark the others noinstr. But not something in between.
>>>
>>> Why this?
>> 
>> Overall it's pretty likely I'm wrong about the subtlety of noinstr's
>> meaning. And the benefits I listed above are pretty minor. I should
>> have looked into this as it would have been an opportunity to reduce
>> the patch count of this RFC!
>> 
>> Maybe I'm also forgetting something more important, perhaps Junaid
>> will weigh in...
>
> Yes, IIRC the idea was that there is no need to prohibit inlining for this class 
> of functions.

I doubt that it works as you want it to work.

+	inline notrace __attribute((__section__(".noinstr.text")))	\

So this explicitely puts the inline into the .noinstr.text section,
which means when it is used in .text the compiler will generate an out-of
line function in the .noinstr.text section and insert a call into the
usage site. That's independent of the size of the inline.

Thanks,

        tglx