Messages in this thread | | | Date | Sat, 31 Jul 2004 23:21:26 -0700 | From | Paul Jackson <> | Subject | Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS |
| |
> 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 - 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/
| |