From: William Lee Irwin III <wli@holomorphy.com>
To: Paul Jackson <pj@sgi.com>
Cc: zwane@linuxpower.ca, linux-kernel@vger.kernel.org, akpm@osdl.org,
colpatch@us.ibm.com
Subject: Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS
Date: Sun, 1 Aug 2004 06:41:12 -0700 [thread overview]
Message-ID: <20040801134112.GU2334@holomorphy.com> (raw)
In-Reply-To: <20040801063632.66c49e61.pj@sgi.com>
On Sun, Aug 01, 2004 at 06:36:32AM -0700, Paul Jackson wrote:
> You mean, in Zwane's example, we'd see a return from any_online_cpu() of
> 32 or 64, not 3 (his NR_CPUS), and not just on i386, but on a majority
> of arch's. That's what you're saying, right?
> Ok ... that favors your preference, teaching the users of find_next_bit
> to be more tolerant.
> Darn. Your min(nbits, ...) patch looks good, but more is needed.
> And could you make it:
> + return min(nbits, find_next_bit(srcp->bits, nbits, n+1));
> rather than:
> + return min(NR_CPUS, find_next_bit(srcp->bits, nbits, n+1));
> for consistency of presentation? All the cpu and node mask macros of
> this form (#define wrapped static inline) use the inline's parameter
> names in the body of the inline, not what the define passed as those
> params, including another 'nbits' in this very line of code.
No problem.
Index: hotplug-2.6.8-rc2/include/linux/cpumask.h
===================================================================
--- hotplug-2.6.8-rc2.orig/include/linux/cpumask.h 2004-07-29 04:44:59.000000000 -0700
+++ hotplug-2.6.8-rc2/include/linux/cpumask.h 2004-08-01 06:32:31.615472016 -0700
@@ -207,13 +207,13 @@
#define first_cpu(src) __first_cpu(&(src), NR_CPUS)
static inline int __first_cpu(const cpumask_t *srcp, int nbits)
{
- return find_first_bit(srcp->bits, nbits);
+ return min_t(int, nbits, find_first_bit(srcp->bits, nbits));
}
#define next_cpu(n, src) __next_cpu((n), &(src), NR_CPUS)
static inline int __next_cpu(int n, const cpumask_t *srcp, int nbits)
{
- return find_next_bit(srcp->bits, nbits, n+1);
+ return min_t(int, nbits, find_next_bit(srcp->bits, nbits, n+1));
}
#define cpumask_of_cpu(cpu) \
next prev parent reply other threads:[~2004-08-01 13:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-31 20:52 [PATCH][2.6] first/next_cpu returns values > NR_CPUS Zwane Mwaikambo
2004-07-31 20:57 ` William Lee Irwin III
2004-07-31 23:02 ` Zwane Mwaikambo
2004-08-01 6:21 ` Paul Jackson
2004-08-01 7:22 ` Zwane Mwaikambo
2004-08-01 11:20 ` Paul Jackson
2004-08-01 14:51 ` Zwane Mwaikambo
2004-08-01 12:40 ` William Lee Irwin III
2004-08-01 13:05 ` Paul Jackson
2004-08-01 13:10 ` William Lee Irwin III
2004-08-01 13:36 ` Paul Jackson
2004-08-01 13:41 ` William Lee Irwin III [this message]
2004-08-01 13:47 ` Paul Jackson
2004-08-02 22:00 ` Matthew Dobson
2004-08-05 16:50 ` OGAWA Hirofumi
2004-08-05 17:01 ` William Lee Irwin III
2004-08-05 17:42 ` Andrew Morton
2004-08-05 18:13 ` Roman Zippel
2004-08-01 14:54 ` Zwane Mwaikambo
2004-08-01 15:05 ` William Lee Irwin III
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040801134112.GU2334@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@osdl.org \
--cc=colpatch@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=zwane@linuxpower.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.