mirror of https://lore.kernel.org/lkml/
 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: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200902051729.n15HTsCC000590@imap1.linux-foundation.org>
2009-02-06  8:17 ` + mm-fix-memmap-init-to-initialize-valid-memmap-for-memory-hole.patch added to -mm tree 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome