lkml.org 
[lkml]   [2004]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][2.6] first/next_cpu returns values > NR_CPUS
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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [from the cache]
©2003-2011 Jasper Spaans