On 05/21/2015 10:36 AM, Brian Norris wrote: > On Thu, May 21, 2015 at 09:50:38AM +0200, Denys Vlasenko wrote: >>>> cfi_udelay(): 74 bytes, 26 callsites >>> >>> ^^ This is pretty dead-simple. If it's generating bad code, we might >>> look at fixing it up instead. Almost all of its call sites are with >>> constant input, so it *should* just become: >>> >>> udelay(1); >>> cond_resched(); >>> >>> in most cases. For the non-constant cases, we might still do an >>> out-of-line implementation. Or maybe we just say it's all not worth it, >>> and we just stick with what you have. But I'd like to consider >>> alternatives to out-lining this one. >> >> You want to consider not-deinlining (IOW: speed-optimizing) > > Inlining isn't always about speed. > >> a *fixed time delay function*? >> >> Think about what delay functions do... > > I wasn't really looking at speed. Just memory usage.
I don't follow. A single, not-inlined cfi_udelay(1) call is a minimal possible code size. Even udelay(1); cond_resched(); ought to be bigger. > And I was only pointing this out because udelay() has a different > implementation for the __builtin_constant_p() case. You can't take > advantage of that for non-inlined versions of cfi_udelay(). > > But that may be irrelevant anyway, now that I think again. At best, > you're trading one function call (arm_delay_ops.const_udelay() on ARM) > for another (cfi_udelay()), since you can never completely optimize out > the latter. *delay() and *sleep() functions are special: they do NOT want to be executed as fast as possible. They are *pausing* execution. They are *intended* to be "slow". You should not strive to optimize out function call overhead when you call one of these. Otherwise, it would mean that you essentially do this for e.g. udelay(NUM): "I want to pause for NUM us, (which is about NUM*3000 CPU cycles), let's optimize out call+ret so that we speed up execution by 5 cycles". Do you see why it does not make sense? -- 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/
