From: Paul Jackson <pj@sgi.com>
To: William Lee Irwin III <wli@holomorphy.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:36:32 -0700 [thread overview]
Message-ID: <20040801063632.66c49e61.pj@sgi.com> (raw)
In-Reply-To: <20040801131004.GT2334@holomorphy.com>
> A strong majority return BITS_PER_LONG-aligned results in this case.
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.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373
next prev parent reply other threads:[~2004-08-01 13:37 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 [this message]
2004-08-01 13:41 ` William Lee Irwin III
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=20040801063632.66c49e61.pj@sgi.com \
--to=pj@sgi.com \
--cc=akpm@osdl.org \
--cc=colpatch@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.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.