On Sat, 31 Jul 2004, Paul Jackson wrote:

When I tried it just now on an ia64 sn2_defconfig, NR_CPUS == 512, it
increased each for_*_cpu() loop about 28 bytes of text, for a kernel
text size increase of 1352 bytes (this is on a private kernel I have,
your results will vary).

I haven't checked the text size increase, but will do.

Could you explain this a bit more?  What value of NR_CPUS were you
using -- if NR_CPUS == 32, then I'd _expect_ any_online_cpu() to return
32 if none of the bits provided it were online.  The way you phrase
this, it sure seems that you are hinting at a bug in the i386 implementation
of find_next_bit().  But I can't quite make out the code, nor what you're
saying, so I'm still confused.

A specific example might help -- NR_CPUS is this, what's online is that,
called "any_online_cpu()" with so-and-so, expected thus as a return, got
something else instead.

I'd hate to see a bug in i386 find_next_bit() left to stand, at the
expense of increasing sometimes fairly interesting code loops by 28
bytes of text each.  If that's what's happening here ...

NR_CPUS was 3, the test case may as well be passing first_cpu or next_cpu
a value of 0 for the map. The "bug" in the i386 find_next_bit really
looks like a feature if you look at the code.