[PATCH v2 3/4] Provide the always inline version of some functions

H. Peter Anvin hpa at zytor.com
Mon Nov 10 15:21:52 PST 2025


On 2025-11-09 03:51, Peter Zijlstra wrote:
> On Sat, Nov 08, 2025 at 02:14:44PM -0800, H. Peter Anvin wrote:
> 
>>> +static struct rq *finish_task_switch(struct task_struct *prev)
>>> +{
>>> +	return finish_task_switch_ainline(prev);
>>> +}
>>> +
>>> /**
>>>  * schedule_tail - first thing a freshly forked thread must call.
>>>  * @prev: the thread we just switched away from.
>>
>> There is, in fact: you have to have an always_inline version, and wrap it in a noinline version.
> 
> Yes, but all of this is particularly retarded, there are exactly _2_
> callers of this function. Keeping an out-of-line copy for one while
> inlineing the other makes 0 sense.
> 
> Also, the amount of crap he needs to mark __always_inline doesn't make
> much sense to me, is he building with -Os or something?

That's another issue -- unless the second instance of the function is on a
slow path which wants to be isolated from the rest of its function (unlikely.)

I was merely commenting on the claim that there is no way to control inlining
on a call site basis - there is.

	-hpa




More information about the linux-riscv mailing list