linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Xishi Qiu <qiuxishi@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	nao.horiguchi@gmail.com, Yinghai Lu <yinghai@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	mingo@elte.hu, Xiexiuqi <xiexiuqi@huawei.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	"Luck, Tony" <tony.luck@intel.com>, Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 00/12] mm: mirrored memory support for page buddy allocations
Date: Thu, 18 Jun 2015 11:55:42 +0200	[thread overview]
Message-ID: <5582959E.4080402@suse.cz> (raw)
In-Reply-To: <55829149.60807@huawei.com>

On 06/18/2015 11:37 AM, Xishi Qiu wrote:
> On 2015/6/18 13:58, Vlastimil Babka wrote:
>
>> On 18.6.2015 3:23, Xishi Qiu wrote:
>>> On 2015/6/16 17:46, Vlastimil Babka wrote:
>>>
>>
>> On the other hand, it would skip just as inefficiently over MIGRATE_MIRROR
>> pageblocks within a Normal zone. Since migrating pages between MIGRATE_MIRROR
>> and other types pageblocks would violate what the allocations requested.
>>
>> Having separate zone instead would allow compaction to run specifically on the
>> zone and defragment movable allocations there (i.e. userspace pages if/when
>> userspace requesting mirrored memory is supported).
>>
>>>>
>>>
>>> Hi Vlastimil,
>>>
>>> If there are many mirror regions in one node, then it will be many holes in the
>>> normal zone, is this fine?
>>
>> Yeah, it doesn't matter how many holes there are.
>
> So mirror zone and normal zone will span each other, right?
>
> e.g. node 1: 4G-8G(normal), 8-12G(mirror), 12-16G(normal), 16-24G(mirror), 24-28G(normal) ...
> normal: start=4G, size=28-4=24G,
> mirror: start=8G, size=24-8=16G,

Yes, that works. It's somewhat unfortunate wrt performance that the 
hardware does it like this though.

> I think zone is defined according to the special address range, like 16M(DMA), 4G(DMA32),

Traditionally yes. But then there is ZONE_MOVABLE, this year's LSF/MM we 
discussed (and didn't outright deny) ZONE_CMA...
I'm not saying others will favour the new zone approach though, it's 
just my opinion that it might be a better option than a new migratetype.

> and is it appropriate to add a new mirror zone with a volatile physical address?

By "volatile" you mean what, that the example above would change 
dynamically? That would be rather challenging...

> Thanks,
> Xishi Qiu
>

--
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>

  reply	other threads:[~2015-06-18  9:55 UTC|newest]

Thread overview: 62+ 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:56 ` [RFC PATCH 01/12] mm: add a new config to manage the code Xishi Qiu
2015-06-08 11:52   ` Leon Romanovsky
2015-06-08 15:14     ` Luck, Tony
2015-06-08 16:36       ` Leon Romanovsky
2015-06-09  6:44   ` Kamezawa Hiroyuki
2015-06-09 10:10     ` Xishi Qiu
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 16:57   ` Luck, Tony
2015-06-05  1:53     ` Xishi Qiu
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-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 13:00 ` [RFC PATCH 05/12] mm: introduce a new zone_stat_item NR_FREE_MIRROR_PAGES Xishi Qiu
2015-06-04 13:01 ` [RFC PATCH 06/12] mm: add free mirrored pages info Xishi Qiu
2015-06-04 13:02 ` [RFC PATCH 07/12] mm: introduce __GFP_MIRROR to allocate mirrored pages Xishi Qiu
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 17:01   ` Luck, Tony
2015-06-04 18:41   ` Dave Hansen
2015-06-05  3:13     ` Xishi Qiu
2015-06-09  7:06   ` Kamezawa Hiroyuki
2015-06-09 10:09     ` Xishi Qiu
2015-06-10  3:09       ` Kamezawa Hiroyuki
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:04 ` [RFC PATCH 10/12] mm: add the buddy system interface Xishi Qiu
2015-06-04 17:09   ` Luck, Tony
2015-06-05  3:14     ` Xishi Qiu
2015-06-09  7:12   ` Kamezawa Hiroyuki
2015-06-09 10:04     ` Xishi Qiu
2015-06-10  3:06       ` Kamezawa Hiroyuki
2015-06-10 20:40         ` Luck, Tony
2015-06-15  8:47           ` Kamezawa Hiroyuki
2015-06-15 17:20             ` Luck, Tony
2015-06-16  0:31               ` Kamezawa Hiroyuki
2015-06-25  9:44         ` Xishi Qiu
2015-06-25 23:54           ` Kamezawa Hiroyuki
2015-06-26  1:43             ` Xishi Qiu
2015-06-26  8:34               ` Kamezawa Hiroyuki
2015-06-26 10:38                 ` Xishi Qiu
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 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 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  9:09   ` Xishi Qiu
2015-06-12 19:03   ` Luck, Tony
2015-06-15  0:25     ` Naoya Horiguchi
2015-06-16  7:53 ` Vlastimil Babka
2015-06-16  8:17   ` Xishi Qiu
2015-06-16  9:46     ` Vlastimil Babka
2015-06-18  1:23       ` Xishi Qiu
2015-06-18  5:58         ` Vlastimil Babka
2015-06-18  9:37           ` Xishi Qiu
2015-06-18  9:55             ` Vlastimil Babka [this message]
2015-06-18 20:33               ` Luck, Tony
2015-06-19  1:36                 ` Xishi Qiu
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=5582959E.4080402@suse.cz \
    --to=vbabka@suse.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).