lkml.org 
[lkml]   [2008]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Alternative implementation of the generic __ffs
On Sun, Apr 20, 2008 at 10:42:21AM +0200, Alexander van Heukelum wrote:
> On Sat, 19 Apr 2008 20:06:57 -0700, "Joe Perches" <joe@perches.com>
> said:
> > On Sun, 2008-04-20 at 01:29 +0300, Matti Aarnio wrote:
> > > I am curious, why not take the code already in glibc ffs() for ARM ?
> > > That is, if the ffs() is all that important detail in kernel ?
>
> Hi,
>
> The glibc version is based on a table-lookup. This makes it
> behave differently in hot and cold cache situations. That's
> fine if __ffs is used in tight loops, but in the kernel such
> use of __ffs is avoided because it might be slow. I added it
> to the benchmark, but it would need testing for the cold
> cache case too.
>
> As for the importance of __ffs in the kernel: as far as I
> know the hot-spots in the kernel using __ffs are the
> schedular (sched_find_first_bit) and the cpu mask walking
> code (for_each_cpu_mask).

Perhaps those hot-spots would benefit from more broadly
accelerable algorithms. ARM architecture v5 introduced
a CLZ instruction -- Count Leading Zeroes.

Well, gcc's __builtin_ffs() for ARM Arch5 and up (including
XScale) does things in a bit more interesting way:

http://mail-index.netbsd.org/port-arm/2002/08/20/0001.html

$ cat try.c
int foo(int i)
{
return __builtin_ffs(i);
}
$ arm-gp2x-linux-gcc -S -O -march=armv5 try.c
$ more try.s
.file "try.c"
.text
.align 2
.global foo
.type foo, %function
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
rsb r3, r0, #0
and r3, r3, r0
clz r3, r3
rsb r0, r3, #32
bx lr
.size foo, .-foo
.ident "GCC: (GNU) 4.1.2 (Fedora GP2X 4.1.2-8.fc9)"

> Greetings,
> Alexander

/Matti Aarnio


\
 
 \ /
  Last update: 2008-04-20 14:35    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site