From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by kanga.kvack.org (Postfix) with ESMTP id DF7796B0253 for ; Mon, 11 Apr 2016 07:04:50 -0400 (EDT) Received: by mail-pa0-f49.google.com with SMTP id ot11so36221122pab.1 for ; Mon, 11 Apr 2016 04:04:50 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com. [119.145.14.65]) by mx.google.com with ESMTPS id g24si2981065pfj.91.2016.04.11.04.04.48 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 11 Apr 2016 04:04:50 -0700 (PDT) Subject: Re: [PATCH 1/2] arm64: mem-model: add flatmem model for arm64 References: <1459844572-53069-1-git-send-email-puck.chen@hisilicon.com> <20160407142148.GI5657@arm.com> <570B10B2.2000000@hisilicon.com> <570B5875.20804@hisilicon.com> <570B758E.7070005@hisilicon.com> <20160411104013.GG15729@arm.com> From: Chen Feng Message-ID: <570B8310.40103@hisilicon.com> Date: Mon, 11 Apr 2016 18:57:20 +0800 MIME-Version: 1.0 In-Reply-To: <20160411104013.GG15729@arm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Will Deacon , Ard Biesheuvel Cc: Mark Rutland , mhocko@suse.com, Laura Abbott , Dan Zhao , Yiping Xu , puck.chen@foxmail.com, albert.lubing@hisilicon.com, Catalin Marinas , suzhuangluan@hisilicon.com, "linux-kernel@vger.kernel.org" , linuxarm@huawei.com, "linux-mm@kvack.org" , kirill.shutemov@linux.intel.com, David Rientjes , oliver.fu@hisilicon.com, Andrew Morton , robin.murphy@arm.com, "linux-arm-kernel@lists.infradead.org" , saberlily.xia@hisilicon.com Hi Will, On 2016/4/11 18:40, Will Deacon wrote: > On Mon, Apr 11, 2016 at 12:31:53PM +0200, Ard Biesheuvel wrote: >> On 11 April 2016 at 11:59, Chen Feng wrote: >>> Please see the pg-tables below. >>> >>> >>> With sparse and vmemmap enable. >>> >>> ---[ vmemmap start ]--- >>> 0xffffffbdc0200000-0xffffffbdc4800000 70M RW NX SHD AF UXN MEM/NORMAL >>> ---[ vmemmap end ]--- >>> >> >> OK, I see what you mean now. Sorry for taking so long to catch up. >> >>> The board is 4GB, and the memap is 70MB >>> 1G memory --- 14MB mem_map array. >> >> No, this is incorrect. 1 GB corresponds with 16 MB worth of struct >> pages assuming sizeof(struct page) == 64 >> >> So you are losing 6 MB to rounding here, which I agree is significant. >> I wonder if it makes sense to use a lower value for SECTION_SIZE_BITS >> on 4k pages kernels, but perhaps we're better off asking the opinion >> of the other cc'ees. > > You need to be really careful making SECTION_SIZE_BITS smaller because > it has a direct correlation on the use of page->flags and you can end up > running out of bits fairly easily. Yes, making SECTION_SIZE_BITS smaller can solve the current situation. But if the phys-addr is 64GB, but only 4GB ddr is the valid address. And the holes are not always 512MB. But, can you tell us why *smaller SIZE makes running out of bits fairly easily*? And how about the flat-mem model? > > Will > > . > -- 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: email@kvack.org