Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS

[Paul Jackson <pj@sgi.com>]

> Zwane, William proposed:
> +	return min(NR_CPUS, find_first_bit(srcp->bits, nbits));

Could you check the kernel text size, for some NUMA config, before and
after adding these min() calls in first_cpu() and next_cpu().  These two
macros are critical to the for_*_cpu() macros.

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).

> The following caused some fireworks whilst merging i386 cpu hotplug.
> any_online_cpu(0x2) returns 32 on i386 if we're forced to continue past
> the only set bit due to the additional find_first_bit in the
> find_next_bit i386 implementation.

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 ... 

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373