All of lore.kernel.org
 help / color / mirror / Atom feed
From: "KAMEZAWA Hiroyuki" <kamezawa.hiroyu@jp.fujitsu.com>
To: "Mel Gorman" <mel@csn.ul.ie>
Cc: "KAMEZAWA Hiroyuki" <kamezawa.hiroyu@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	mm-commits@vger.kernel.org, davem@davemloft.net,
	heiko.carstens@de.ibm.com, stable@kernel.org
Subject: Re: [BUGFIX][PATCH] Aditional fix for memmap initalization
Date: Tue, 10 Feb 2009 23:27:08 +0900 (JST)	[thread overview]
Message-ID: <4b20a06e0fecb87fb8da5f510595573b.squirrel@webmail-b.css.fujitsu.com> (raw)
In-Reply-To: <20090210133326.GA4023@csn.ul.ie>

Mel Gorman wrote:
> It feels like we are changing more than we need to.
agreed.

> Could we achieve the same
> fix by just altering early_pfn_in_nid() to return true if the PFN matches
> the NID or is in a hole and ok to initialise.  Something like this patch
> maybe?
>
yes, maybe.
It seems there is no additional bug report and it seems good to write
simpler patch. I'll try a replacement in this week.

Regards,
-Kame

> =====
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 09c14e2..c3140df 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1070,11 +1070,7 @@ void sparse_init(void);
>  #define sparse_index_init(_sec, _nid)  do {} while (0)
>  #endif /* CONFIG_SPARSEMEM */
>
> -#ifdef CONFIG_NODES_SPAN_OTHER_NODES
> -#define early_pfn_in_nid(pfn, nid)	(early_pfn_to_nid(pfn) == (nid))
> -#else
> -#define early_pfn_in_nid(pfn, nid)	(1)
> -#endif
> +int __meminit early_pfn_in_nid(unsigned long pfn, int nid);
>
>  #ifndef early_pfn_valid
>  #define early_pfn_valid(pfn)	(1)
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 5675b30..708837e 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3005,6 +3005,34 @@ int __meminit early_pfn_to_nid(unsigned long pfn)
>  }
>  #endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
>
> +#ifdef CONFIG_NODES_SPAN_OTHER_NODES
> +/*
> + * Returns true if the PFN is within the NID or it is within a hole.
> + * If the PFN is in a hole, we still initialise the memmap so that
> + * walkers of the memmap do not get confused
> + */
> +int __meminit early_pfn_in_nid(unsigned long pfn, int nid)
> +{
> +	int i;
> +
> +	for (i = 0; i < nr_nodemap_entries; i++) {
> +		unsigned long start_pfn = early_node_map[i].start_pfn;
> +		unsigned long end_pfn = early_node_map[i].end_pfn;
> +
> +		if (start_pfn <= pfn && pfn < end_pfn)
> +			return early_node_map[i].nid == nid;
> +	}
> +
> +	/* The PFN is within a hole so it'll be ok to initialise */
> +	return 1;
> +}
> +#else
> +int __meminit early_pfn_in_nid(unsigned long pfn, int nid)
> +{
> +	return 1;
> +}
> +#endif
> +
>  /* Basic iterator support to walk early_node_map[] */
>  #define for_each_active_range_index_in_nid(i, nid) \
>  	for (i = first_active_region_index_in_nid(nid); i != -1; \
>
> --
> Mel Gorman
> Part-time Phd Student                          Linux Technology Center
> University of Limerick                         IBM Dublin Software Lab
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



      reply	other threads:[~2009-02-10 14:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-05 17:29 + mm-fix-memmap-init-to-initialize-valid-memmap-for-memory-hole.patch added to -mm tree akpm
2009-02-06  8:17 ` KAMEZAWA Hiroyuki
2009-02-06  9:55   ` [BUGFIX][PATCH] Aditional fix for memmap initalization KAMEZAWA Hiroyuki
2009-02-10 13:28     ` Mel Gorman
2009-02-10 13:33     ` Mel Gorman
2009-02-10 14:27       ` KAMEZAWA Hiroyuki [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=4b20a06e0fecb87fb8da5f510595573b.squirrel@webmail-b.css.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=mm-commits@vger.kernel.org \
    --cc=stable@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.