All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Matthew Dobson <colpatch@us.ibm.com>
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 21:37:00 +0000	[thread overview]
Message-ID: <20021028213700.D11734@flint.arm.linux.org.uk> (raw)
In-Reply-To: <3DBD9434.5050601@us.ibm.com>; from colpatch@us.ibm.com on Mon, Oct 28, 2002 at 11:47:00AM -0800

On Mon, Oct 28, 2002 at 11:47:00AM -0800, Matthew Dobson wrote:
> 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.

I missed this bit.

> > 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.

To me, it seems inappropriate to litter header files that contain
nothing to do with memory management with stuff from memory management
when other headers that already contain memory management bits get
ignored.  This type of practice is why we've ended up with #include
hell in the kernel today.

> > 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.
>
> 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...

I'm in agreement with you here.

> If you feel param.h is the wrong place, I originally had the #define's 
> in asm/topology.h.

This seems like a good solution - linux/mmzone.h already includes this
file, so it wouldn't be adding all that much to the #include hell.
Also, asm-generic/topology.h contains stuff to do with numa/discontig
already, so it seems perfect.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


  reply	other threads:[~2002-10-28 21:30 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
2002-10-28 21:37     ` Russell King [this message]
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=20021028213700.D11734@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=colpatch@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjbligh@us.ibm.com \
    --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.