public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Bob Picco <bob.picco@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [patch 3/4] ia64 SPARSEMEM - conditional changes for SPARSEMEM
Date: Mon, 23 May 2005 21:17:20 +0000	[thread overview]
Message-ID: <20050523211720.GI2783@localhost.localdomain> (raw)
In-Reply-To: <20050523175107.GF2783@localhost.localdomain>

Jesse Barnes wrote:	[Mon May 23 2005, 02:14:48PM EDT]
> On Monday, May 23, 2005 10:51 am, Bob Picco wrote:
> > This patch introduces the conditional changes required for the three
> > memory models.  With [patch 1/4] there are three memory model
> > FLATMEM, DISCONTIG and SPARSEMEM.  Also a new arch include file
> > sparemem.h is introduced for defining SPARSEMEM parameters.
> 
> This looks like a good start at untangling CONFIG_DISCONTIGMEM and 
> CONFIG_NUMA.  Yay!
> 
> > -#ifdef CONFIG_VIRTUAL_MEM_MAP
> > +#ifdef	CONFIG_VIRTUAL_MEM_MAP
> 
> You can drop this hunk, right?
Yup.
> 
> >  extern int ia64_pfn_valid (unsigned long pfn);
> > -#else
> > +#elif	CONFIG_FLATMEM
> 
> Space instead of tab?
Yup.
> 
> >  # define ia64_pfn_valid(pfn) 1
> >  #endif
> >
> > -#ifndef CONFIG_DISCONTIGMEM
> > +#ifdef	CONFIG_FLATMEM
> 
> Ditto, and a few more later.
> 
> > -#define __pa(x)		({ia64_va _v; _v.l = (long) (x); _v.f.reg = 0;
> > _v.l;}) -#define __va(x)		({ia64_va _v; _v.l = (long) (x); _v.f.reg > > -1; _v.p;}) +#define __pa(x)	({							\
> > +	ia64_va _v; 							\
> > +	_v.l = (long) (x); 						\
> > +	_v.f.reg = 0; 							\
> > +	_v.l;								\
> > +})
> > +#define __va(x)	({							\
> > +	ia64_va _v;							\
> > +	_v.l = (long) (x);						\
> > +	_v.f.reg = -1;							\
> > +	_v.p;								\
> > +})
> 
> This looks like unrelated (but good) cleanup.  Should probably be 
> submitted separately along with similar cleanups for the other macros 
> (e.g. REGION_NUMBER, REGION_OFFSET).
Okay. I'll revert and do a separate cleanup later.
> 
> > +/* until we think of something better */
> > +#define	page_is_ram(pfn)	1
> 
> This macro could consult the EFI memory map (maybe only returning true 
> if the page was WB enabled?).  Does it have to be fast?
Arg.  This is extraneous.  I think it was required to stub around hotplug
memory simulation.  I'll remove.
> 
> Jesse
thanks,

bob

      parent reply	other threads:[~2005-05-23 21:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-23 17:51 [patch 3/4] ia64 SPARSEMEM - conditional changes for SPARSEMEM Bob Picco
2005-05-23 18:14 ` Jesse Barnes
2005-05-23 21:17 ` Bob Picco [this message]

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=20050523211720.GI2783@localhost.localdomain \
    --to=bob.picco@hp.com \
    --cc=linux-ia64@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox