On Mon, 28 Apr 2008, Linus Torvalds wrote:
quoted text
> > > > How about making the optimization controlled by a config switch so
> > > > arch maintainers can decide whether they want to enable the constant
> > > > optimization or unconditionally call the lib function ?
> > > 
> > > No.
> > > 
> > > This is just making that damn header line look worse and worse.
> > > 
> > > Is there a _reason_ to optimize this stupid function this way?
> > 
> > On architectures which have a find bit instruction we can replace the
> > call to the library function by a single instruction when the size of
> > the bitmap is less/equal bits per long and when the bitnr is a
> > constant.
> 
> That's not what I asked.
> 
> I asked whether there is a *reason* to optimize this and cause all these 
> stupid problems.
> 
> Is there a real hot path anywhere that actually uses this and depends on 
> it?

Sorry, misunderstood your question. 

I checked the use cases and have not found a single one for
find_next_(zero_)bit() which makes use of this micro optimization. In
fact the .text section of vmlinux of the "optimized" and the straight
function call are identical. So the effect of those micro
optimizations is exactly zero.

find_first_(zero_)bit() has a couple of places where the optimization
hits, but the code size reduction is mere 21 bytes and the use cases
are not in real hot pathes AFAICT.

I doubt that that is worth the trouble and we should just remove those
inlines alltogether. This was discussed before, but Andi objected to
remove those micro optimizations and nobody had time to actually
verify the real benefits.

I'll whip up a patch.

Thanks,

	tglx
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/