Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754331AbbLQSnY (ORCPT ); Thu, 17 Dec 2015 13:43:24 -0500 Received: from mga11.intel.com ([192.55.52.93]:41838 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753536AbbLQSnX convert rfc822-to-8bit (ORCPT ); Thu, 17 Dec 2015 13:43:23 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,442,1444719600"; d="scan'208";a="873700522" From: "Luck, Tony" To: Kamezawa Hiroyuki , Xishi Qiu CC: "Izumi, Taku" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "mel@csn.ul.ie" , "Hansen, Dave" , "matt@codeblueprint.co.uk" Subject: RE: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option Thread-Topic: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option Thread-Index: AQHRMjAhAQ0e9br7T0uYMif+yG96M57ChRIAgACu/pCAAL3uAIAASYOAgAAKFICAAYydgIAAQHeAgAjmdICAABNEAIAAAY+AgAAgD4CAAAPQAIAAUa3Q Date: Thu, 17 Dec 2015 18:43:20 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F39F882E8@ORSMSX114.amr.corp.intel.com> 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> <56691819.3040105@huawei.com> <566A9AE1.7020001@huawei.com> <56722258.6030800@huawei.com> <567223A7.9090407@jp.fujitsu.com> <56723E8B.8050201@huawei.com> <567241BE.5030806@jp.fujitsu.com> In-Reply-To: <567241BE.5030806@jp.fujitsu.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGNiNmUyODctZjczYi00NjhhLWE3NzUtM2ZlMzI4MjM0MDNjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjQuMTAuMTkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRGZmQ3RqSlwvcEpBMk5LQTc3K0ZUT3dWdFBHVVpNR1NXdUVvNWU0TU9iQ2M9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1859 Lines: 40 >>> As Tony requested, we may need a knob to stop a fallback in "movable->normal", later. >>> >> >> If the mirrored memory is small and the other is large, >> I think we can both enable "non-mirrored -> normal" and "normal -> non-mirrored". > > Size of mirrored memory can be configured by software(EFI var). > So, having both is just overkill and normal->non-mirroed fallback is meaningless considering > what the feature want to guarantee. In the original removable usage we wanted to guarantee that Linux did not allocate any kernel objects in removable memory - because that would prevent later removal of that memory. Mirror case is the same - we don't want to allocate kernel structures in non-mirrored memory because an uncorrectable error in one of them would crash the system. But I think some users might like some flexibility here. If the system doesn't have enough memory for the kernel (non-movable or mirrored), then it seems odd to end up crashing the system at the point of memory exhaustion (a likely result ... the kernel can try to reclaim some pages from SLAB, but that might only return a few pages, if the shortage continues the system will perform poorly and eventually fail). The whole point of removable memory or mirrored memory is to provide better availability. I'd vote for a mode where running out of memory for kernel results in a warn_on_once("Ran out of mirrored/non-removable memory for kernel - now allocating from all zones\n") because I think most people would like the system to stay up rather than worry about some future problem that may never happen. -Tony -- 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/