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

From: Zwane Mwaikambo (zwane_at_linuxpower.ca)
Date: 08/01/04

  • Next message: Anton Blanchard: "Re: [PATCH] use for_each_cpu" 
    Date:	Sun, 1 Aug 2004 03:22:56 -0400 (EDT)
To: Paul Jackson <pj@sgi.com>

    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/

  • Next message: Anton Blanchard: "Re: [PATCH] use for_each_cpu"

    Relevant Pages

    • Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS
      ... On Sun, 1 Aug 2004, Paul Jackson wrote: ... >> looks like a feature if you look at the code. ... > What code, what feature, what bug ... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS
      ... increased each for_*_cpuloop about 28 bytes of text, for a kernel ... I'd hate to see a bug in i386 find_next_bitleft to stand, ... expense of increasing sometimes fairly interesting code loops by 28 ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: AGP problem SiS 746FX Linux 2.6.5-rc3
      ... the Empire squashes the Federation like a bug. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.9bk6 msdos fs OOPS
      ... >This bug is triggered by race condition. ... Apparently my lashup doesn't trigger it. ... Copyright 2004 by Maurice Eugene Heskett, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch 0/3] j_state_lock, j_list_lock, remove-bitlocks
      ... BUG: Unable to handle kernel NULL pointer dereference at virtual address ... TAS_BUFFER_FNS(RevokeValid, revokevalid) ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)