All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Alexey Dobriyan <adobriyan@mail.ru>
Cc: Andrew Morton <akpm@osdl.org>, Andy Whitcroft <apw@shadowen.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.11-mm1 (x86-abstract-discontigmem-setup.patch)
Date: Sat, 05 Mar 2005 10:58:57 -0800	[thread overview]
Message-ID: <1110049138.6446.3.camel@localhost> (raw)
In-Reply-To: <200503051535.24372.adobriyan@mail.ru>

On Sat, 2005-03-05 at 15:35 +0200, Alexey Dobriyan wrote:
> > +	}
> > +	printk(KERN_DEBUG "\n");
> 	       ^^^^^^^^^^
> > +}
> 
> Too much KERN_DEBUG.

On my system, that ends up printing out 4 or 5 lines of output per node,
but it's quite invaluable if you're debugging early memory setup issues.
It is KERN_DEBUG after all.  What does it do on your system?

I'm not horribly opposed to removing some of this output, let's just
make sure...

> > --- 25/include/linux/mmzone.h~x86-abstract-discontigmem-setup
> > +++ 25-akpm/include/linux/mmzone.h
> 
> > +#ifdef CONFIG_HAVE_MEMORY_PRESENT
> > +void memory_present(int nid, unsigned long start, unsigned long end);
> > +#else
> > +static inline void memory_present(int nid, unsigned long start, unsigned long end) {}
> > +#endif
> 
> > +#ifdef CONFIG_NEED_NODE_MEMMAP_SIZE
> > +unsigned long __init node_memmap_size_bytes(int, unsigned long, unsigned long);
> > +#endif
> 
> 	#else
> 	static inline unsigned long node_memmap_size_bytes(...);
> 	#endif
> 
> Is this needed?

It's really only used for the i386 NUMA architectures, but it is
necessary.  We'll be overriding that discontigmem version for sparsemem,
which I'll be submitting soon:

http://www.sr71.net/patches/2.6.11/2.6.11-mhp1/broken-out/B-sparse-150-sparsemem.patch


-- Dave


  reply	other threads:[~2005-03-05 19:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-05 13:35 2.6.11-mm1 (x86-abstract-discontigmem-setup.patch) Alexey Dobriyan
2005-03-05 18:58 ` Dave Hansen [this message]
2005-03-05 23:21   ` Alexey Dobriyan
2005-03-07 21:16     ` Dave Hansen
2005-03-07 21:19     ` Dave Hansen

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=1110049138.6446.3.camel@localhost \
    --to=haveblue@us.ibm.com \
    --cc=adobriyan@mail.ru \
    --cc=akpm@osdl.org \
    --cc=apw@shadowen.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.