[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