Messages in this thread | | | Subject | Re: [PATCH] x86: Change x86 to use generic find_next_bit | From | Andi Kleen <> | Date | 09 Mar 2008 22:03:42 +0100 |
| |
Ingo Molnar <mingo@elte.hu> writes: > > the generic version in lib/find_next_bit.c is open-coded C which gcc can > optimize pretty nicely. > > the hand-coded assembly versions in arch/x86/lib/bitops_32.c mostly use > the special x86 'bit search forward' (BSF) instruction - which i know > from the days when the scheduler relied on it has some non-trivial setup
~14 cycles on K8 for memory, but if you stay in a register it is 8 cycles
> costs. So especially when there's _small_ bitmasks involved, it's more > expensive.
I had a patchkit some time ago to special case the max_bit <= 63 case and always use directly inlined stream lined single instruction assembler for that. There was still some issue and I dropped it then, but doing something like that makes still sense. Even if the BSF is slightly slower than the open coded version just getting rid of the CALL will make it a win and it could be also kept in a register so you get the 8 cycle variant (for which I doubt you can do it faster open coded)
The result would be that a standard for_each_cpu () in a NR_CPUS <= 64 kernel wouldn't have any unnecessary calls.
In general the problem of walking cpu masks is quite different from seaching ext2 bitmaps, so they likely should be special cased and optimized for each.
-Andi
| |