All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Taku Izumi <izumi.taku@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	tony.luck@intel.com, qiuxishi@huawei.com,
	kamezawa.hiroyu@jp.fujitsu.com, mel@csn.ul.ie,
	dave.hansen@intel.com, matt@codeblueprint.co.uk
Subject: Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option
Date: Mon, 28 Dec 2015 14:32:24 -0800	[thread overview]
Message-ID: <20151228143224.86787a0ee1c343e1b2db36dc@linux-foundation.org> (raw)
In-Reply-To: <1449631177-14863-1-git-send-email-izumi.taku@jp.fujitsu.com>

On Wed,  9 Dec 2015 12:19:37 +0900 Taku Izumi <izumi.taku@jp.fujitsu.com> wrote:

> This patch extends existing "kernelcore" option and
> introduces kernelcore=mirror option. By specifying
> "mirror" instead of specifying the amount of memory,
> non-mirrored (non-reliable) region will be arranged
> into ZONE_MOVABLE.
> 
> v1 -> v2:
>  - Refine so that the following case also can be
>    handled properly:
> 
>  Node X:  |MMMMMM------MMMMMM--------|
>    (legend) M: mirrored  -: not mirrrored
> 
>  In this case, ZONE_NORMAL and ZONE_MOVABLE are
>  arranged like bellow:
> 
>  Node X:  |MMMMMM------MMMMMM--------|
>           |ooooooxxxxxxooooooxxxxxxxx| ZONE_NORMAL
>                 |ooooooxxxxxxoooooooo| ZONE_MOVABLE
>    (legend) o: present  x: absent
> 
> ...
>
>
> @@ -5507,6 +5569,36 @@ static void __init find_zone_movable_pfns_for_nodes(void)
>  	}
>  
>  	/*
> +	 * If kernelcore=mirror is specified, ignore movablecore option
> +	 */
> +	if (mirrored_kernelcore) {
> +		bool mem_below_4gb_not_mirrored = false;
> +
> +		for_each_memblock(memory, r) {
> +			if (memblock_is_mirror(r))
> +				continue;
> +
> +			nid = r->nid;
> +
> +			usable_startpfn = memblock_region_memory_base_pfn(r);
> +
> +			if (usable_startpfn < 0x100000) {
> +				mem_below_4gb_not_mirrored = true;
> +				continue;
> +			}
> +
> +			zone_movable_pfn[nid] = zone_movable_pfn[nid] ?
> +				min(usable_startpfn, zone_movable_pfn[nid]) :
> +				usable_startpfn;
> +		}
> +
> +		if (mem_below_4gb_not_mirrored)
> +			pr_warn("This configuration results in unmirrored kernel memory.");

This looks a bit strange.

What's the code actually doing?  Checking to see that all memory at
physical addresses < 0x100000000 is mirrored, I think?

If so, what's up with that hard-wired 0x100000?  That's not going to
work on PAGE_SIZE>4k machines, and this is generic code.

Also, I don't think the magical 0x100000000 is necessarily going to be
relevant for other architectures (presumably powerpc will be next...)

I guess this is all OK as an "initial implementation for x86_64 only"
for now, and this stuff will be changed later if/when another
architecture comes along.  However it would be nice to make things more
generic from the outset, to provide a guide for how things should be
implemented by other architectures.



Separately, what feedback does the user get about the success of the
kernelcore=mirror comment?  We didn't include an explicit printk which
displays the outcome, so how is the user to find out that it all worked
OK and that the kernel is now using mirrored memory?


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Taku Izumi <izumi.taku@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	tony.luck@intel.com, qiuxishi@huawei.com,
	kamezawa.hiroyu@jp.fujitsu.com, mel@csn.ul.ie,
	dave.hansen@intel.com, matt@codeblueprint.co.uk
Subject: Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option
Date: Mon, 28 Dec 2015 14:32:24 -0800	[thread overview]
Message-ID: <20151228143224.86787a0ee1c343e1b2db36dc@linux-foundation.org> (raw)
In-Reply-To: <1449631177-14863-1-git-send-email-izumi.taku@jp.fujitsu.com>

On Wed,  9 Dec 2015 12:19:37 +0900 Taku Izumi <izumi.taku@jp.fujitsu.com> wrote:

> This patch extends existing "kernelcore" option and
> introduces kernelcore=mirror option. By specifying
> "mirror" instead of specifying the amount of memory,
> non-mirrored (non-reliable) region will be arranged
> into ZONE_MOVABLE.
> 
> v1 -> v2:
>  - Refine so that the following case also can be
>    handled properly:
> 
>  Node X:  |MMMMMM------MMMMMM--------|
>    (legend) M: mirrored  -: not mirrrored
> 
>  In this case, ZONE_NORMAL and ZONE_MOVABLE are
>  arranged like bellow:
> 
>  Node X:  |MMMMMM------MMMMMM--------|
>           |ooooooxxxxxxooooooxxxxxxxx| ZONE_NORMAL
>                 |ooooooxxxxxxoooooooo| ZONE_MOVABLE
>    (legend) o: present  x: absent
> 
> ...
>
>
> @@ -5507,6 +5569,36 @@ static void __init find_zone_movable_pfns_for_nodes(void)
>  	}
>  
>  	/*
> +	 * If kernelcore=mirror is specified, ignore movablecore option
> +	 */
> +	if (mirrored_kernelcore) {
> +		bool mem_below_4gb_not_mirrored = false;
> +
> +		for_each_memblock(memory, r) {
> +			if (memblock_is_mirror(r))
> +				continue;
> +
> +			nid = r->nid;
> +
> +			usable_startpfn = memblock_region_memory_base_pfn(r);
> +
> +			if (usable_startpfn < 0x100000) {
> +				mem_below_4gb_not_mirrored = true;
> +				continue;
> +			}
> +
> +			zone_movable_pfn[nid] = zone_movable_pfn[nid] ?
> +				min(usable_startpfn, zone_movable_pfn[nid]) :
> +				usable_startpfn;
> +		}
> +
> +		if (mem_below_4gb_not_mirrored)
> +			pr_warn("This configuration results in unmirrored kernel memory.");

This looks a bit strange.

What's the code actually doing?  Checking to see that all memory at
physical addresses < 0x100000000 is mirrored, I think?

If so, what's up with that hard-wired 0x100000?  That's not going to
work on PAGE_SIZE>4k machines, and this is generic code.

Also, I don't think the magical 0x100000000 is necessarily going to be
relevant for other architectures (presumably powerpc will be next...)

I guess this is all OK as an "initial implementation for x86_64 only"
for now, and this stuff will be changed later if/when another
architecture comes along.  However it would be nice to make things more
generic from the outset, to provide a guide for how things should be
implemented by other architectures.



Separately, what feedback does the user get about the success of the
kernelcore=mirror comment?  We didn't include an explicit printk which
displays the outcome, so how is the user to find out that it all worked
OK and that the kernel is now using mirrored memory?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2015-12-28 22:32 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09  3:18 [PATCH v3 0/2] mm: Introduce kernelcore=mirror option Taku Izumi
2015-12-09  3:18 ` Taku Izumi
2015-12-09  3:19 ` [PATCH v3 1/2] mm: Calculate zone_start_pfn at zone_spanned_pages_in_node() Taku Izumi
2015-12-09  3:19   ` Taku Izumi
2015-12-09  3:19 ` [PATCH v3 2/2] mm: Introduce kernelcore=mirror option Taku Izumi
2015-12-09  3:19   ` Taku Izumi
2015-12-09  3:28   ` Xishi Qiu
2015-12-09  3:28     ` Xishi Qiu
2015-12-09 21:59     ` Luck, Tony
2015-12-09 21:59       ` Luck, Tony
2015-12-10  1:14       ` Xishi Qiu
2015-12-10  1:14         ` Xishi Qiu
2015-12-10  5:37         ` Izumi, Taku
2015-12-10  5:37           ` Izumi, Taku
2015-12-10  6:13           ` Xishi Qiu
2015-12-10  6:13             ` Xishi Qiu
2015-12-11  5:53             ` Izumi, Taku
2015-12-11  5:53               ` Izumi, Taku
2015-12-11  9:44               ` Xishi Qiu
2015-12-11  9:44                 ` Xishi Qiu
2015-12-17  1:38                 ` Izumi, Taku
2015-12-17  1:38                   ` Izumi, Taku
2015-12-17  2:47                   ` Xishi Qiu
2015-12-17  2:47                     ` Xishi Qiu
2015-12-17  2:53                     ` Kamezawa Hiroyuki
2015-12-17  2:53                       ` Kamezawa Hiroyuki
2015-12-17  4:48                       ` Xishi Qiu
2015-12-17  4:48                         ` Xishi Qiu
2015-12-17  5:01                         ` Kamezawa Hiroyuki
2015-12-17  5:01                           ` Kamezawa Hiroyuki
2015-12-17 18:43                           ` Luck, Tony
2015-12-17 18:43                             ` Luck, Tony
2015-12-18  2:12                             ` Kamezawa Hiroyuki
2015-12-18  2:12                               ` Kamezawa Hiroyuki
2015-12-18  6:59                               ` Luck, Tony
2015-12-18  6:59                                 ` Luck, Tony
2015-12-28 22:21   ` Andrew Morton
2015-12-28 22:21     ` Andrew Morton
2015-12-28 22:32   ` Andrew Morton [this message]
2015-12-28 22:32     ` Andrew Morton

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=20151228143224.86787a0ee1c343e1b2db36dc@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mel@csn.ul.ie \
    --cc=qiuxishi@huawei.com \
    --cc=tony.luck@intel.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.