Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754150AbbFOIsQ (ORCPT ); Mon, 15 Jun 2015 04:48:16 -0400 Received: from mgwym01.jp.fujitsu.com ([211.128.242.40]:32976 "EHLO mgwym01.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754080AbbFOIsC (ORCPT ); Mon, 15 Jun 2015 04:48:02 -0400 X-SecurityPolicyCheck: OK by SHieldMailChecker v2.3.2 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20150223 X-SHieldMailCheckerMailID: 8bdd997bb7404247a0414e67060f6670 Message-ID: <557E911F.5040602@jp.fujitsu.com> Date: Mon, 15 Jun 2015 17:47:27 +0900 From: Kamezawa Hiroyuki User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Luck, Tony" , Xishi Qiu CC: Andrew Morton , "nao.horiguchi@gmail.com" , Yinghai Lu , "H. Peter Anvin" , Thomas Gleixner , "mingo@elte.hu" , Xiexiuqi , Hanjun Guo , Linux MM , LKML Subject: Re: [RFC PATCH 10/12] mm: add the buddy system interface References: <55704A7E.5030507@huawei.com> <55704CC4.8040707@huawei.com> <557691E0.5020203@jp.fujitsu.com> <5576BA2B.6060907@huawei.com> <5577A9A9.7010108@jp.fujitsu.com> <3908561D78D1C84285E8C5FCA982C28F32A8F209@ORSMSX114.amr.corp.intel.com> In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F32A8F209@ORSMSX114.amr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1655 Lines: 37 On 2015/06/11 5:40, Luck, Tony wrote: >> I guess, mirrored memory should be allocated if !__GFP_HIGHMEM or !__GFP_MOVABLE > > HIGHMEM shouldn't matter - partial memory mirror only makes any sense on X86_64 systems ... 32-bit kernels > don't even boot on systems with 64GB, and the minimum rational configuration for a machine that supports > mirror is 128GB (4 cpu sockets * 2 memory controller per socket * 4 channels per controller * 4GB DIMM ... > leaving any channels empty likely leaves you short of memory bandwidth for these high core count processors). > > MOVABLE is mostly the opposite of MIRROR - we never want to fill a kernel allocation from a MOVABLE page. I > want all kernel allocations to be from MIRROR. > 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) Thanks, -Kame -- 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/