Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753285AbbLJGRh (ORCPT ); Thu, 10 Dec 2015 01:17:37 -0500 Received: from szxga03-in.huawei.com ([119.145.14.66]:31628 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752673AbbLJGRg (ORCPT ); Thu, 10 Dec 2015 01:17:36 -0500 Message-ID: <56691819.3040105@huawei.com> Date: Thu, 10 Dec 2015 14:13:45 +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: "Izumi, Taku" CC: "Luck, Tony" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "Kamezawa, Hiroyuki" , "mel@csn.ul.ie" , "Hansen, Dave" , "matt@codeblueprint.co.uk" Subject: Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option References: <1449631109-14756-1-git-send-email-izumi.taku@jp.fujitsu.com> <1449631177-14863-1-git-send-email-izumi.taku@jp.fujitsu.com> <56679FDC.1080800@huawei.com> <3908561D78D1C84285E8C5FCA982C28F39F7F4CD@ORSMSX114.amr.corp.intel.com> <5668D1FA.4050108@huawei.com> In-Reply-To: Content-Type: text/plain; charset="ISO-2022-JP" 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.0A020203.56691827.00BD,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: b2b35bec5b8fcc2af76fc6409ea5a59c Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1986 Lines: 66 On 2015/12/10 13:37, Izumi, Taku wrote: > Dear Tony, Xishi, > >>>> How about add some comment, if mirrored memroy is too small, then the >>>> normal zone is small, so it may be oom. >>>> The mirrored memory is at least 1/64 of whole memory, because struct >>>> pages usually take 64 bytes per page. >>> >>> 1/64th is the absolute lower bound (for the page structures as you say). I >>> expect people will need to configure 10% or more to run any real workloads. > >>> >>> I made the memblock boot time allocator fall back to non-mirrored memory >>> if mirrored memory ran out. What happens in the run time allocator if the >>> non-movable zones run out of pages? Will we allocate kernel pages from movable >>> memory? >>> >> >> As I know, the kernel pages will not allocated from movable zone. > > Yes, kernel pages are not allocated from ZONE_MOVABLE. > > In this case administrator must review and reconfigure the mirror ratio via > "MirrorRequest" EFI variable. > > Sincerely, > Taku Izumi > Hi Taku, Whether it is possible that we rewrite the fallback function in buddy system when zone_movable and mirrored_kernelcore are both enabled? It seems something like that we add a new zone but the name is zone_movable, not zone_mirror. And the prerequisite is that we won't enable these two features(movable memory and mirrored memory) at the same time. Thus we can reuse the code of movable zone. Thanks, Xishi Qiu >> >>> -- >>> 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/ >>> >>> . >>> >> >> > > > . > -- 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/