[lkml]   [2004]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.018 / U:8.744 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site