Re: [PATCH v2] kthread: Export kthread functions

[Jes Sorensen <Jes.Sorensen@redhat.com>]

yalin wang <yalin.wang2010@gmail.com> writes:
>> On Aug 1, 2015, at 21:32, Neil Horman <nhorman@redhat.com> wrote:
>>> strange,  this is my test result:
>>> 
>>> size   built-in.o*
>>>  text	   data	    bss	    dec	    hex	filename
>>> 743937 50786 56008 850731 cfb2b built-in.o // with the patch
>>> 744069 50786 56008 850863 cfbaf built-in.o_old // with out the
>>> patch
>>> 
>> So you're willing to expose the internals of kthread_park in exchange for the
>> hope of saving 132 bytes of text.
>> 
>> Thats just dumb.  I agree with tglx, this shouldn't change.
>> 
>> Neil
> not just size, mainly for performance,
> without inline:
>
> ffffffc0000d26b0: 97fff4aa bl ffffffc0000cf958 <kthread_should_park>
> ffffffc0000d26b4:       53001c00        uxtb    w0, w0
>
> if kthread_should_park() inline:
> ffffffc0000d1a44: f85c8020 ldr x0, [x1,#-56] // kthread_should_park
> line
> ffffffc0000d1a48: 36100300 tbz w0, #2, ffffffc0000d1aa8
> <smpboot_thread_fn+0xbc> // kthread_should_park line
>
> still use 2 instructions, but don’t need a function call,
> maybe can do more optimisation by gcc sometimes .
> Anyway, this is just a suggest,
> it is up to you apply it or not. :) 

kthread_park() isn't exactly a performance critical function call.
Saving two instructions does not outway the cost of exposing the
internals of the kthread API.

Jes