From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Xishi Qiu <qiuxishi@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
"nao.horiguchi@gmail.com" <nao.horiguchi@gmail.com>,
Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
"mingo@elte.hu" <mingo@elte.hu>, Xiexiuqi <xiexiuqi@huawei.com>,
Hanjun Guo <guohanjun@huawei.com>, Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 10/12] mm: add the buddy system interface
Date: Tue, 16 Jun 2015 09:31:42 +0900 [thread overview]
Message-ID: <557F6E6E.9060104@jp.fujitsu.com> (raw)
In-Reply-To: <20150615172023.GA12088@agluck-desk.sc.intel.com>
On 2015/06/16 2:20, Luck, Tony wrote:
> On Mon, Jun 15, 2015 at 05:47:27PM +0900, Kamezawa Hiroyuki wrote:
>> So, there are 3 ideas.
>>
>> (1) kernel only from MIRROR / user only from MOVABLE (Tony)
>> (2) kernel only from MIRROR / user from MOVABLE + MIRROR(ASAP) (AKPM suggested)
>> This makes use of the fact MOVABLE memory is reclaimable but Tony pointed out
>> the memory reclaim can be critical for GFP_ATOMIC.
>> (3) kernel only from MIRROR / user from MOVABLE, special user from MIRROR (Xishi)
>>
>> 2 Implementation ideas.
>> - creating ZONE
>> - creating new alloation attribute
>>
>> I don't convince whether we need some new structure in mm. Isn't it good to use
>> ZONE_MOVABLE for not-mirrored memory ?
>> Then, disable fallback from ZONE_MOVABLE -> ZONE_NORMAL for (1) and (3)
>
> We might need to rename it ... right now the memory hotplug
> people use ZONE_MOVABLE to indicate regions of physical memory
> that can be removed from the system. I'm wondering whether
> people will want systems that have both removable and mirrored
> areas? Then we have four attribute combinations:
>
> mirror=no removable=no - prefer to use for user, could use for kernel if we run out of mirror
> mirror=no removable=yes - can only be used for user (kernel allocation makes it not-removable)
> mirror=yes removable=no - use for kernel, possibly for special users if we define some interface
> mirror=yes removable=yes - must not use for kernel ... would have to give to user ... seems like a bad idea to configure a system this way
>
Thank you for clarification. I see "mirror=no, removable=no" case may require a new name.
IMHO, the value of Address-Based-Memory-Mirror is that users can protect their system's
important functions without using full-memory mirror. So, I feel thinking
"mirror=no, removable=no" just makes our discussion/implemenation complex without real
user value.
Shouldn't we start with just thiking 2 cases of
mirror=no removable=yes
mirror=yes removable=no
?
And then, if the naming is problem, alias name can be added.
Thanks,
-Kame
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Xishi Qiu <qiuxishi@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
"nao.horiguchi@gmail.com" <nao.horiguchi@gmail.com>,
Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
"mingo@elte.hu" <mingo@elte.hu>, Xiexiuqi <xiexiuqi@huawei.com>,
Hanjun Guo <guohanjun@huawei.com>, Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 10/12] mm: add the buddy system interface
Date: Tue, 16 Jun 2015 09:31:42 +0900 [thread overview]
Message-ID: <557F6E6E.9060104@jp.fujitsu.com> (raw)
In-Reply-To: <20150615172023.GA12088@agluck-desk.sc.intel.com>
On 2015/06/16 2:20, Luck, Tony wrote:
> On Mon, Jun 15, 2015 at 05:47:27PM +0900, Kamezawa Hiroyuki wrote:
>> So, there are 3 ideas.
>>
>> (1) kernel only from MIRROR / user only from MOVABLE (Tony)
>> (2) kernel only from MIRROR / user from MOVABLE + MIRROR(ASAP) (AKPM suggested)
>> This makes use of the fact MOVABLE memory is reclaimable but Tony pointed out
>> the memory reclaim can be critical for GFP_ATOMIC.
>> (3) kernel only from MIRROR / user from MOVABLE, special user from MIRROR (Xishi)
>>
>> 2 Implementation ideas.
>> - creating ZONE
>> - creating new alloation attribute
>>
>> I don't convince whether we need some new structure in mm. Isn't it good to use
>> ZONE_MOVABLE for not-mirrored memory ?
>> Then, disable fallback from ZONE_MOVABLE -> ZONE_NORMAL for (1) and (3)
>
> We might need to rename it ... right now the memory hotplug
> people use ZONE_MOVABLE to indicate regions of physical memory
> that can be removed from the system. I'm wondering whether
> people will want systems that have both removable and mirrored
> areas? Then we have four attribute combinations:
>
> mirror=no removable=no - prefer to use for user, could use for kernel if we run out of mirror
> mirror=no removable=yes - can only be used for user (kernel allocation makes it not-removable)
> mirror=yes removable=no - use for kernel, possibly for special users if we define some interface
> mirror=yes removable=yes - must not use for kernel ... would have to give to user ... seems like a bad idea to configure a system this way
>
Thank you for clarification. I see "mirror=no, removable=no" case may require a new name.
IMHO, the value of Address-Based-Memory-Mirror is that users can protect their system's
important functions without using full-memory mirror. So, I feel thinking
"mirror=no, removable=no" just makes our discussion/implemenation complex without real
user value.
Shouldn't we start with just thiking 2 cases of
mirror=no removable=yes
mirror=yes removable=no
?
And then, if the naming is problem, alias name can be added.
Thanks,
-Kame
next prev parent reply other threads:[~2015-06-16 0:32 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-04 12:54 [RFC PATCH 00/12] mm: mirrored memory support for page buddy allocations Xishi Qiu
2015-06-04 12:54 ` Xishi Qiu
2015-06-04 12:56 ` [RFC PATCH 01/12] mm: add a new config to manage the code Xishi Qiu
2015-06-04 12:56 ` Xishi Qiu
2015-06-08 11:52 ` Leon Romanovsky
2015-06-08 11:52 ` Leon Romanovsky
2015-06-08 15:14 ` Luck, Tony
2015-06-08 15:14 ` Luck, Tony
2015-06-08 16:36 ` Leon Romanovsky
2015-06-08 16:36 ` Leon Romanovsky
2015-06-09 6:44 ` Kamezawa Hiroyuki
2015-06-09 6:44 ` Kamezawa Hiroyuki
2015-06-09 10:10 ` Xishi Qiu
2015-06-09 10:10 ` Xishi Qiu
2015-06-10 3:07 ` Kamezawa Hiroyuki
2015-06-10 3:07 ` Kamezawa Hiroyuki
2015-06-04 12:57 ` [RFC PATCH 02/12] mm: introduce mirror_info Xishi Qiu
2015-06-04 12:57 ` Xishi Qiu
2015-06-04 16:57 ` Luck, Tony
2015-06-04 16:57 ` Luck, Tony
2015-06-05 1:53 ` Xishi Qiu
2015-06-05 1:53 ` Xishi Qiu
2015-06-09 6:48 ` Kamezawa Hiroyuki
2015-06-09 6:48 ` Kamezawa Hiroyuki
2015-06-04 12:58 ` [RFC PATCH 03/12] mm: introduce MIGRATE_MIRROR to manage the mirrored, pages Xishi Qiu
2015-06-04 12:58 ` Xishi Qiu
2015-06-09 6:54 ` Kamezawa Hiroyuki
2015-06-09 6:54 ` Kamezawa Hiroyuki
2015-06-04 12:59 ` [RFC PATCH 04/12] mm: add mirrored pages to buddy system Xishi Qiu
2015-06-04 12:59 ` Xishi Qiu
2015-06-04 13:00 ` [RFC PATCH 05/12] mm: introduce a new zone_stat_item NR_FREE_MIRROR_PAGES Xishi Qiu
2015-06-04 13:00 ` Xishi Qiu
2015-06-04 13:01 ` [RFC PATCH 06/12] mm: add free mirrored pages info Xishi Qiu
2015-06-04 13:01 ` Xishi Qiu
2015-06-04 13:02 ` [RFC PATCH 07/12] mm: introduce __GFP_MIRROR to allocate mirrored pages Xishi Qiu
2015-06-04 13:02 ` Xishi Qiu
2015-06-09 7:01 ` Kamezawa Hiroyuki
2015-06-09 7:01 ` Kamezawa Hiroyuki
2015-06-04 13:02 ` [RFC PATCH 08/12] mm: use mirrorable to switch allocate mirrored memory Xishi Qiu
2015-06-04 13:02 ` Xishi Qiu
2015-06-04 17:01 ` Luck, Tony
2015-06-04 17:01 ` Luck, Tony
2015-06-04 18:41 ` Dave Hansen
2015-06-04 18:41 ` Dave Hansen
2015-06-05 3:13 ` Xishi Qiu
2015-06-05 3:13 ` Xishi Qiu
2015-06-09 7:06 ` Kamezawa Hiroyuki
2015-06-09 7:06 ` Kamezawa Hiroyuki
2015-06-09 10:09 ` Xishi Qiu
2015-06-09 10:09 ` Xishi Qiu
2015-06-10 3:09 ` Kamezawa Hiroyuki
2015-06-10 3:09 ` Kamezawa Hiroyuki
2015-06-12 8:05 ` Naoya Horiguchi
2015-06-12 8:05 ` Naoya Horiguchi
2015-06-04 13:03 ` [RFC PATCH 09/12] mm: enable allocate mirrored memory at boot time Xishi Qiu
2015-06-04 13:03 ` Xishi Qiu
2015-06-04 13:04 ` [RFC PATCH 10/12] mm: add the buddy system interface Xishi Qiu
2015-06-04 13:04 ` Xishi Qiu
2015-06-04 17:09 ` Luck, Tony
2015-06-04 17:09 ` Luck, Tony
2015-06-05 3:14 ` Xishi Qiu
2015-06-05 3:14 ` Xishi Qiu
2015-06-09 7:12 ` Kamezawa Hiroyuki
2015-06-09 7:12 ` Kamezawa Hiroyuki
2015-06-09 10:04 ` Xishi Qiu
2015-06-09 10:04 ` Xishi Qiu
2015-06-10 3:06 ` Kamezawa Hiroyuki
2015-06-10 3:06 ` Kamezawa Hiroyuki
2015-06-10 20:40 ` Luck, Tony
2015-06-10 20:40 ` Luck, Tony
2015-06-15 8:47 ` Kamezawa Hiroyuki
2015-06-15 8:47 ` Kamezawa Hiroyuki
2015-06-15 17:20 ` Luck, Tony
2015-06-15 17:20 ` Luck, Tony
2015-06-16 0:31 ` Kamezawa Hiroyuki [this message]
2015-06-16 0:31 ` Kamezawa Hiroyuki
2015-06-25 9:44 ` Xishi Qiu
2015-06-25 9:44 ` Xishi Qiu
2015-06-25 23:54 ` Kamezawa Hiroyuki
2015-06-25 23:54 ` Kamezawa Hiroyuki
2015-06-26 1:43 ` Xishi Qiu
2015-06-26 1:43 ` Xishi Qiu
2015-06-26 8:34 ` Kamezawa Hiroyuki
2015-06-26 8:34 ` Kamezawa Hiroyuki
2015-06-26 10:38 ` Xishi Qiu
2015-06-26 10:38 ` Xishi Qiu
2015-06-26 18:42 ` Luck, Tony
2015-06-26 18:42 ` Luck, Tony
2015-06-04 13:04 ` [RFC PATCH 11/12] mm: add the PCP interface Xishi Qiu
2015-06-04 13:04 ` Xishi Qiu
2015-06-04 18:44 ` Dave Hansen
2015-06-04 18:44 ` Dave Hansen
2015-06-04 13:05 ` [RFC PATCH 12/12] mm: let slab/slub/slob use mirrored memory Xishi Qiu
2015-06-04 13:05 ` Xishi Qiu
2015-06-04 17:14 ` Luck, Tony
2015-06-04 17:14 ` Luck, Tony
2015-06-12 8:42 ` [RFC PATCH 00/12] mm: mirrored memory support for page buddy allocations Naoya Horiguchi
2015-06-12 8:42 ` Naoya Horiguchi
2015-06-12 9:09 ` Xishi Qiu
2015-06-12 9:09 ` Xishi Qiu
2015-06-12 19:03 ` Luck, Tony
2015-06-12 19:03 ` Luck, Tony
2015-06-15 0:25 ` Naoya Horiguchi
2015-06-15 0:25 ` Naoya Horiguchi
2015-06-16 7:53 ` Vlastimil Babka
2015-06-16 7:53 ` Vlastimil Babka
2015-06-16 8:17 ` Xishi Qiu
2015-06-16 8:17 ` Xishi Qiu
2015-06-16 9:46 ` Vlastimil Babka
2015-06-16 9:46 ` Vlastimil Babka
2015-06-18 1:23 ` Xishi Qiu
2015-06-18 1:23 ` Xishi Qiu
2015-06-18 5:58 ` Vlastimil Babka
2015-06-18 5:58 ` Vlastimil Babka
2015-06-18 9:37 ` Xishi Qiu
2015-06-18 9:37 ` Xishi Qiu
2015-06-18 9:55 ` Vlastimil Babka
2015-06-18 9:55 ` Vlastimil Babka
2015-06-18 20:33 ` Luck, Tony
2015-06-18 20:33 ` Luck, Tony
2015-06-19 1:36 ` Xishi Qiu
2015-06-19 1:36 ` Xishi Qiu
2015-06-19 18:42 ` Luck, Tony
2015-06-19 18:42 ` Luck, Tony
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=557F6E6E.9060104@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=guohanjun@huawei.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=nao.horiguchi@gmail.com \
--cc=qiuxishi@huawei.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=xiexiuqi@huawei.com \
--cc=yinghai@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.