yalin wang <[email protected]> writes: >> On Aug 1, 2015, at 21:32, Neil Horman <[email protected]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
