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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/