Messages in this thread | | | Date | Mon, 28 Apr 2008 21:26:11 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH] bitops: simplify generic bit finding functions |
| |
On Mon, 28 Apr 2008, Linus Torvalds wrote: > > > > 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
| |