From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752643AbdCALBO (ORCPT ); Wed, 1 Mar 2017 06:01:14 -0500 Received: from mx0b-0016f401.pphosted.com ([67.231.156.173]:54814 "EHLO mx0b-0016f401.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752389AbdCAK7v (ORCPT ); Wed, 1 Mar 2017 05:59:51 -0500 Date: Wed, 1 Mar 2017 18:41:40 +0800 From: Jisheng Zhang To: zhouxianrong , Chen Feng , Catalin Marinas CC: Ard Biesheuvel , "linux-mm@kvack.org" , Mark Rutland , Kefeng Wang , , , Will Deacon , , , , Alexander Kuleshov , , , , , "linux-arm-kernel@lists.infradead.org" , Steve Capper , "linux-kernel@vger.kernel.org" , Joe Perches , Dennis Chen , Andrew Morton , Ganapatrao Kulkarni Subject: Re: [PATCH] mm: free reserved area's memmap if possiable Message-ID: <20170301184140.7ac9de0a@xhacker> In-Reply-To: References: <1486987349-58711-1-git-send-email-zhouxianrong@huawei.com> <1487055180-128750-1-git-send-email-zhouxianrong@huawei.com> <04630153-bc82-ac1f-2f80-344c90200732@huawei.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-01_07:,, signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1703010102 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Add Chen, Catalin On Thu, 16 Feb 2017 09:11:29 +0800 zhouxianrong wrote: > > > On 2017/2/15 15:10, Ard Biesheuvel wrote: > > On 15 February 2017 at 01:44, zhouxianrong wrote: > >> > >> > >> On 2017/2/14 17:03, Ard Biesheuvel wrote: > >>> > >>> On 14 February 2017 at 06:53, wrote: > >>>> > >>>> From: zhouxianrong > >>>> > >>>> just like freeing no-map area's memmap (gaps of memblock.memory) > >>>> we could free reserved area's memmap (areas of memblock.reserved) > >>>> as well only when user of reserved area indicate that we can do > >>>> this in drivers. that is, user of reserved area know how to > >>>> use the reserved area who could not memblock_free or free_reserved_xxx > >>>> the reserved area and regard the area as raw pfn usage by kernel. > >>>> the patch supply a way to users who want to utilize the memmap > >>>> memory corresponding to raw pfn reserved areas as many as possible. > >>>> users can do this by memblock_mark_raw_pfn interface which mark the > >>>> reserved area as raw pfn and tell free_unused_memmap that this area's > >>>> memmap could be freeed. > >>>> > >>> > >>> Could you give an example how much memory we actually recover by doing > >>> this? I understand it depends on the size of the reserved regions, but > >>> I'm sure you have an actual example that inspired you to write this > >>> patch. > >> > >> > >> i did statistics in our platform, the memmap of reserved region that can be > >> freed > >> is about 6MB. it's fewer. <...> > >>> In any case, it is good to emphasize that on 4 KB pagesize kernels, we > >>> will only free multiples of 8 MB that are 8 MB aligned, resulting in > >>> 128 KB of memmap backing to be released. > >> > >> > >> > >>> > >>> > >>>> + if (start < end) > >>>> + free_memmap(start, end); > >>>> + } > >>>> } > >>>> #endif /* !CONFIG_SPARSEMEM_VMEMMAP */ > >>>> > >>>> diff --git a/include/linux/memblock.h b/include/linux/memblock.h > >>>> index 5b759c9..9f8d277 100644 > >>>> --- a/include/linux/memblock.h > >>>> +++ b/include/linux/memblock.h > >>>> @@ -26,6 +26,7 @@ enum { > >>>> MEMBLOCK_HOTPLUG = 0x1, /* hotpluggable region */ > >>>> MEMBLOCK_MIRROR = 0x2, /* mirrored region */ > >>>> MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct > >>>> mapping */ > >>>> + MEMBLOCK_RAW_PFN = 0x8, /* region whose memmap never be > >>>> used */ > >>> > >>> > >>> I think we should be *very* careful about the combinatorial explosion > >>> that results when combining all these flags, given that this is not a > >>> proper enum but a bit field. > >>> > >>> In any case, the generic memblock change should be in a separate patch > >>> from the arm64 change. > >> > >> > >> MEMBLOCK_RAW_PFN and MEMBLOCK_NOMAP can not be set at the same time > >> > > > > They should not. But if I call memblock_mark_raw_pfn() on a > > MEMBLOCK_NOMAP region, it will have both flags set. > > > > In summary, I don't think we need this patch. And if you can convince > > us otherwise, you should really be more methodical and explicit in > > implementing this RAW_PFN flag, not add it as a byproduct of the arch > > code that uses it. Also, you should explain how RAW_PFN relates to > > NOMAP, and ensure that RAW_PFN and NOMAP regions don't intersect if > > that is an unsupported combination. > > yes, setting both MEMBLOCK_RAW_PFN and MEMBLOCK_NOMAP could meet some problems > when gaps of memblock.memory intersect memblock.reserved. if they do not intersect, > that's ok. so as you said this should be carefully considered. > > as you think this patch is not needed because, i have showed my idea, it's enough, thanks! we are also interested in this area. Just curious, is this patch to "free the vmemmap holes" mentioned by by Catalin in [1]? [1]http://lkml.iu.edu/hypermail/linux/kernel/1604.1/03036.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.161.200]) by kanga.kvack.org (Postfix) with ESMTP id 4F33C6B038C for ; Wed, 1 Mar 2017 05:46:49 -0500 (EST) Received: by mail-yw0-f200.google.com with SMTP id 203so66691500ywz.2 for ; Wed, 01 Mar 2017 02:46:49 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com. [67.231.156.173]) by mx.google.com with ESMTPS id z65si488664ywb.199.2017.03.01.02.46.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 02:46:48 -0800 (PST) Date: Wed, 1 Mar 2017 18:41:40 +0800 From: Jisheng Zhang Subject: Re: [PATCH] mm: free reserved area's memmap if possiable Message-ID: <20170301184140.7ac9de0a@xhacker> In-Reply-To: References: <1486987349-58711-1-git-send-email-zhouxianrong@huawei.com> <1487055180-128750-1-git-send-email-zhouxianrong@huawei.com> <04630153-bc82-ac1f-2f80-344c90200732@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: zhouxianrong , Chen Feng , Catalin Marinas Cc: Ard Biesheuvel , "linux-mm@kvack.org" , Mark Rutland , Kefeng Wang , srikar@linux.vnet.ibm.com, Mi.Sophia.Wang@huawei.com, Will Deacon , zhangshiming5@huawei.com, zijun_hu@htc.com, won.ho.park@huawei.com, Alexander Kuleshov , chengang@emindsoft.com.cn, zhouxiyu@huawei.com, tj@kernel.org, weidu.du@huawei.com, "linux-arm-kernel@lists.infradead.org" , Steve Capper , "linux-kernel@vger.kernel.org" , Joe Perches , Dennis Chen , Andrew Morton , Ganapatrao Kulkarni Add Chen, Catalin On Thu, 16 Feb 2017 09:11:29 +0800 zhouxianrong wrote: > > > On 2017/2/15 15:10, Ard Biesheuvel wrote: > > On 15 February 2017 at 01:44, zhouxianrong wrote: > >> > >> > >> On 2017/2/14 17:03, Ard Biesheuvel wrote: > >>> > >>> On 14 February 2017 at 06:53, wrote: > >>>> > >>>> From: zhouxianrong > >>>> > >>>> just like freeing no-map area's memmap (gaps of memblock.memory) > >>>> we could free reserved area's memmap (areas of memblock.reserved) > >>>> as well only when user of reserved area indicate that we can do > >>>> this in drivers. that is, user of reserved area know how to > >>>> use the reserved area who could not memblock_free or free_reserved_xxx > >>>> the reserved area and regard the area as raw pfn usage by kernel. > >>>> the patch supply a way to users who want to utilize the memmap > >>>> memory corresponding to raw pfn reserved areas as many as possible. > >>>> users can do this by memblock_mark_raw_pfn interface which mark the > >>>> reserved area as raw pfn and tell free_unused_memmap that this area's > >>>> memmap could be freeed. > >>>> > >>> > >>> Could you give an example how much memory we actually recover by doing > >>> this? I understand it depends on the size of the reserved regions, but > >>> I'm sure you have an actual example that inspired you to write this > >>> patch. > >> > >> > >> i did statistics in our platform, the memmap of reserved region that can be > >> freed > >> is about 6MB. it's fewer. <...> > >>> In any case, it is good to emphasize that on 4 KB pagesize kernels, we > >>> will only free multiples of 8 MB that are 8 MB aligned, resulting in > >>> 128 KB of memmap backing to be released. > >> > >> > >> > >>> > >>> > >>>> + if (start < end) > >>>> + free_memmap(start, end); > >>>> + } > >>>> } > >>>> #endif /* !CONFIG_SPARSEMEM_VMEMMAP */ > >>>> > >>>> diff --git a/include/linux/memblock.h b/include/linux/memblock.h > >>>> index 5b759c9..9f8d277 100644 > >>>> --- a/include/linux/memblock.h > >>>> +++ b/include/linux/memblock.h > >>>> @@ -26,6 +26,7 @@ enum { > >>>> MEMBLOCK_HOTPLUG = 0x1, /* hotpluggable region */ > >>>> MEMBLOCK_MIRROR = 0x2, /* mirrored region */ > >>>> MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct > >>>> mapping */ > >>>> + MEMBLOCK_RAW_PFN = 0x8, /* region whose memmap never be > >>>> used */ > >>> > >>> > >>> I think we should be *very* careful about the combinatorial explosion > >>> that results when combining all these flags, given that this is not a > >>> proper enum but a bit field. > >>> > >>> In any case, the generic memblock change should be in a separate patch > >>> from the arm64 change. > >> > >> > >> MEMBLOCK_RAW_PFN and MEMBLOCK_NOMAP can not be set at the same time > >> > > > > They should not. But if I call memblock_mark_raw_pfn() on a > > MEMBLOCK_NOMAP region, it will have both flags set. > > > > In summary, I don't think we need this patch. And if you can convince > > us otherwise, you should really be more methodical and explicit in > > implementing this RAW_PFN flag, not add it as a byproduct of the arch > > code that uses it. Also, you should explain how RAW_PFN relates to > > NOMAP, and ensure that RAW_PFN and NOMAP regions don't intersect if > > that is an unsupported combination. > > yes, setting both MEMBLOCK_RAW_PFN and MEMBLOCK_NOMAP could meet some problems > when gaps of memblock.memory intersect memblock.reserved. if they do not intersect, > that's ok. so as you said this should be carefully considered. > > as you think this patch is not needed because, i have showed my idea, it's enough, thanks! we are also interested in this area. Just curious, is this patch to "free the vmemmap holes" mentioned by by Catalin in [1]? [1]http://lkml.iu.edu/hypermail/linux/kernel/1604.1/03036.html -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: jszhang@marvell.com (Jisheng Zhang) Date: Wed, 1 Mar 2017 18:41:40 +0800 Subject: [PATCH] mm: free reserved area's memmap if possiable In-Reply-To: References: <1486987349-58711-1-git-send-email-zhouxianrong@huawei.com> <1487055180-128750-1-git-send-email-zhouxianrong@huawei.com> <04630153-bc82-ac1f-2f80-344c90200732@huawei.com> Message-ID: <20170301184140.7ac9de0a@xhacker> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Add Chen, Catalin On Thu, 16 Feb 2017 09:11:29 +0800 zhouxianrong wrote: > > > On 2017/2/15 15:10, Ard Biesheuvel wrote: > > On 15 February 2017 at 01:44, zhouxianrong wrote: > >> > >> > >> On 2017/2/14 17:03, Ard Biesheuvel wrote: > >>> > >>> On 14 February 2017 at 06:53, wrote: > >>>> > >>>> From: zhouxianrong > >>>> > >>>> just like freeing no-map area's memmap (gaps of memblock.memory) > >>>> we could free reserved area's memmap (areas of memblock.reserved) > >>>> as well only when user of reserved area indicate that we can do > >>>> this in drivers. that is, user of reserved area know how to > >>>> use the reserved area who could not memblock_free or free_reserved_xxx > >>>> the reserved area and regard the area as raw pfn usage by kernel. > >>>> the patch supply a way to users who want to utilize the memmap > >>>> memory corresponding to raw pfn reserved areas as many as possible. > >>>> users can do this by memblock_mark_raw_pfn interface which mark the > >>>> reserved area as raw pfn and tell free_unused_memmap that this area's > >>>> memmap could be freeed. > >>>> > >>> > >>> Could you give an example how much memory we actually recover by doing > >>> this? I understand it depends on the size of the reserved regions, but > >>> I'm sure you have an actual example that inspired you to write this > >>> patch. > >> > >> > >> i did statistics in our platform, the memmap of reserved region that can be > >> freed > >> is about 6MB. it's fewer. <...> > >>> In any case, it is good to emphasize that on 4 KB pagesize kernels, we > >>> will only free multiples of 8 MB that are 8 MB aligned, resulting in > >>> 128 KB of memmap backing to be released. > >> > >> > >> > >>> > >>> > >>>> + if (start < end) > >>>> + free_memmap(start, end); > >>>> + } > >>>> } > >>>> #endif /* !CONFIG_SPARSEMEM_VMEMMAP */ > >>>> > >>>> diff --git a/include/linux/memblock.h b/include/linux/memblock.h > >>>> index 5b759c9..9f8d277 100644 > >>>> --- a/include/linux/memblock.h > >>>> +++ b/include/linux/memblock.h > >>>> @@ -26,6 +26,7 @@ enum { > >>>> MEMBLOCK_HOTPLUG = 0x1, /* hotpluggable region */ > >>>> MEMBLOCK_MIRROR = 0x2, /* mirrored region */ > >>>> MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct > >>>> mapping */ > >>>> + MEMBLOCK_RAW_PFN = 0x8, /* region whose memmap never be > >>>> used */ > >>> > >>> > >>> I think we should be *very* careful about the combinatorial explosion > >>> that results when combining all these flags, given that this is not a > >>> proper enum but a bit field. > >>> > >>> In any case, the generic memblock change should be in a separate patch > >>> from the arm64 change. > >> > >> > >> MEMBLOCK_RAW_PFN and MEMBLOCK_NOMAP can not be set at the same time > >> > > > > They should not. But if I call memblock_mark_raw_pfn() on a > > MEMBLOCK_NOMAP region, it will have both flags set. > > > > In summary, I don't think we need this patch. And if you can convince > > us otherwise, you should really be more methodical and explicit in > > implementing this RAW_PFN flag, not add it as a byproduct of the arch > > code that uses it. Also, you should explain how RAW_PFN relates to > > NOMAP, and ensure that RAW_PFN and NOMAP regions don't intersect if > > that is an unsupported combination. > > yes, setting both MEMBLOCK_RAW_PFN and MEMBLOCK_NOMAP could meet some problems > when gaps of memblock.memory intersect memblock.reserved. if they do not intersect, > that's ok. so as you said this should be carefully considered. > > as you think this patch is not needed because, i have showed my idea, it's enough, thanks! we are also interested in this area. Just curious, is this patch to "free the vmemmap holes" mentioned by by Catalin in [1]? [1]http://lkml.iu.edu/hypermail/linux/kernel/1604.1/03036.html