lkml.org 
[lkml]   [2008]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] x86: Change x86 to use generic find_next_bit
From
Date
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



\
 
 \ /
  Last update: 2008-03-09 22:07    [W:0.169 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site