On Thu, May 21, 2015 at 12:13:10PM +0200, Denys Vlasenko wrote: > 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.
That's not really true. If all cases could be inlined to a single udelay/msleep call, then that would be the minimal code size; you'd save the non-inlined copy that would just call to msleep/udelay, as well as save the need for additional EXPORT_SYBMOL_*(). But in most realistic cases (including this case), your patch is in fact optimal. My follow up comment (trimmed from below) was intended to concede that I was a little off-base in my request. Thanks for putting up, even though some of your comments are tackling a straw man (I never mentioned performance). Thanks, Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
