patch for samba-2.0.7/source/source/lib/bitmap.c (PATCH#96)

[Kenichi Okuyama]

>>>>> "JA" == Jeremy Allison <jeremy at valinux.com> writes:
>> I already don't remember which one is this patch, but I remember
>> that using ffs() ( glibc function ) version instead of
>> find_clear_bit() was the fastest, for it was being inlined by
>> gcc, into machine specific instructions.
JA> But how much of the overall time of Samba is spent in
JA> that code ? That's what Andrew meant when asking for profile
JA> information.

2%. If overall only means time being spent inside smbd, and does not
include kernel status.

# smbd is spending 20-30% of entire CPU, rest is being spent
# by kernel. So, bitmap is only spending 0.4-0.6% of entire CPU
# time.

For this, I needed to measure with rdtsc instruction of
Pentium. Now-a-day CPU was too fast, and Samba is spending too long
time inside kernel to use gprof ( in most cases, gprof picked up the
point where they entered system call, and since so, did not work
properly as good sampling ).

I used Linux 2.2.16 kernel, netbench 7.0 for load.
# It was before 2.4.0 was released.


JA> Without knowing how much *overall* time is spent in that
JA> code and knowing that this is where the bottleneck is,
JA> all this is reducing the number of angels dancing on a
JA> pinhead....

I don't really know if this point is really angels dancing on a
pinhead or not. It's simply that I found it, so I report it. Bitmap
treatment routine are quite independent from rest of the parts, and
easy to test independently.

Since so, even if gain was 0.1%, I thought it worth.

regards,
---- 
Kenichi Okuyama