From: Matthew Dobson <colpatch@us.ibm.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
William Lee Irwin III <wli@holomorphy.com>,
Martin Bligh <mjbligh@us.ibm.com>
Subject: Re: [rfc][patch] MAX_NR_NODES vs. MAX_NUMNODES
Date: Mon, 28 Oct 2002 11:47:00 -0800 [thread overview]
Message-ID: <3DBD9434.5050601@us.ibm.com> (raw)
In-Reply-To: 20021025100028.A19335@flint.arm.linux.org.uk
Russell King wrote:
> On Thu, Oct 24, 2002 at 05:38:22PM -0700, Matthew Dobson wrote:
>
>>Anyone who is more familiar with some of the architectures I mucked with
>>(arm, alpha, ppc64), please let me know if what I've done looks wrong.
>
> Well, this breaks ARM. ARM needs MAX_NR_NODES even for the non-discontig
> mem case. Also, I really don't like the idea of re-using param.h for
> something else - if its going to hoover up random constants, then its
> going to create the usual mess, where if you change one constant that's
> used in 1% of files, 100% of files gets rebuilt.
Hmmm... MAX_NR_NODES is *definitely* available in the non-discontig
case. In include/linux/param.h, MAX_NR_NODES (ifndef'd) is defined to
be 1. This is the generic case. linux/param.h first includes
asm/param.h, so the architecture has the chance to define MAX_NR_NODES
as appropriate for the specific arch. Also, for clps711x and sa1100,
MAX_NR_NODES is defined to be 4, as it NR_NODES was before the change.
Are you sure this is really broken? Have you tried out the patch? I'd
do it myself, but I don't have any access to appropriate machines.
> That is why arm has asm/memory.h to contain everything related to memory
> translation and discontig memory.
This isn't *just* a discontig change. CONFIG_DISCONTIGMEM is a
convenient option to key off of, but as the kernel becomes more and more
NUMA aware, the number of nodes in the system becomes a useful bit of
information to more and more of the code. *That* is why (along with a
suggestion from wli) I put the #defines in param.h.
> It would be better if it remained in mmzone.h for non-arm, and the
> memory.h files for arm. I really never understood why numnodes.h was
> created when mmzone.h has works adequately well since 2.3.
The entire point of this patch is to make this sort of thing *more*
consistent. If this is really that bad for arm, then we can just forget
the patch. I have no desire to increase the complexity of this, or at
best keep it the same. As mentioned in the original post, I was trying
to kill a bunch of (seemingly) unnecessary .h files (the numnodes.h's
specifically), and remove the MAX_[NUM|NR_]NODES duality. If that can't
be accomplished, then all this would do is move the confusion around,
and I don't want that...
If you feel param.h is the wrong place, I originally had the #define's
in asm/topology.h. I feel that is also an appropriate place, exists for
every architecture, and my second choice. I could fairly easily retool
the patch to use that if that is decided to be more appropriate.
If you could give the patch a second read-through, noting the points in
my first paragraph, I would really appreciate it. If you still think
it's broken, we can try and work out how to fix it, or we can drop it.
Cheers!
-Matt
next prev parent reply other threads:[~2002-10-28 19:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-25 0:38 [rfc][patch] MAX_NR_NODES vs. MAX_NUMNODES Matthew Dobson
2002-10-25 9:00 ` Russell King
2002-10-28 19:47 ` Matthew Dobson [this message]
2002-10-28 21:37 ` Russell King
2002-10-28 23:18 ` Matthew Dobson
2002-11-01 2:21 ` Anton Blanchard
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=3DBD9434.5050601@us.ibm.com \
--to=colpatch@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjbligh@us.ibm.com \
--cc=rmk@arm.linux.org.uk \
--cc=wli@holomorphy.com \
/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.