From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751818AbbFPISg (ORCPT ); Tue, 16 Jun 2015 04:18:36 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:18985 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752518AbbFPISa (ORCPT ); Tue, 16 Jun 2015 04:18:30 -0400 Message-ID: <557FDB9B.1090105@huawei.com> Date: Tue, 16 Jun 2015 16:17:31 +0800 From: Xishi Qiu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Vlastimil Babka CC: Andrew Morton , , Yinghai Lu , "H. Peter Anvin" , "Thomas Gleixner" , , Xiexiuqi , Hanjun Guo , "Luck, Tony" , Linux MM , LKML Subject: Re: [RFC PATCH 00/12] mm: mirrored memory support for page buddy allocations References: <55704A7E.5030507@huawei.com> <557FD5F8.10903@suse.cz> In-Reply-To: <557FD5F8.10903@suse.cz> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.25.179] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.557FDBB1.00AA,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b2183e411aaaa16894eef9a65fc7622a Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015/6/16 15:53, Vlastimil Babka wrote: > On 06/04/2015 02:54 PM, Xishi Qiu wrote: >> Intel Xeon processor E7 v3 product family-based platforms introduces support >> for partial memory mirroring called as 'Address Range Mirroring'. This feature >> allows BIOS to specify a subset of total available memory to be mirrored (and >> optionally also specify whether to mirror the range 0-4 GB). This capability >> allows user to make an appropriate tradeoff between non-mirrored memory range >> and mirrored memory range thus optimizing total available memory and still >> achieving highly reliable memory range for mission critical workloads and/or >> kernel space. >> >> Tony has already send a patchset to supprot this feature at boot time. >> https://lkml.org/lkml/2015/5/8/521 >> >> This patchset can support the feature after boot time. It introduces mirror_info >> to save the mirrored memory range. Then use __GFP_MIRROR to allocate mirrored >> pages. >> >> I think add a new migratetype is btter and easier than a new zone, so I use > > If the mirrored memory is in a single reasonably compact (no large holes) range > (per NUMA node) and won't dynamically change its size, then zone might be a > better option. For one thing, it will still allow distinguishing movable and > unmovable allocations within the mirrored memory. > > We had enough fun with MIGRATE_CMA and all kinds of checks it added to allocator > hot paths, and even CMA is now considering moving to a separate zone. > Hi, how about the problem of this case: e.g. node 0: 0-4G(dma and dma32) node 1: 4G-8G(normal), 8-12G(mirror), 12-16G(normal), so more than one normal zone in a node? or normal zone just span the mirror zone? Thanks, Xishi Qiu