[{"id":1424254,"web_url":"http://patchwork.ozlabs.org/comment/1424254/","msgid":"<09d5b30e-5956-bf64-5f4c-ea5425d7f7a5@suse.cz>","date":"2016-08-05T06:45:03","subject":"Re: [PATCH V2 1/2] mm/page_alloc: Replace set_dma_reserve to\n\tset_memory_reserve","submitter":{"id":48129,"url":"http://patchwork.ozlabs.org/api/people/48129/","name":"Vlastimil Babka","email":"vbabka@suse.cz"},"content":"On 08/04/2016 07:12 PM, Srikar Dronamraju wrote:\n> Expand the scope of the existing dma_reserve to accommodate other memory\n> reserves too. Accordingly rename variable dma_reserve to\n> nr_memory_reserve.\n>\n> set_memory_reserve also takes a new parameter that helps to identify if\n> the current value needs to be incremented.\n>\n> Suggested-by: Mel Gorman \n> Signed-off-by: Srikar Dronamraju \n> ---\n> arch/x86/kernel/e820.c | 2 +-\n> include/linux/mm.h | 2 +-\n> mm/page_alloc.c | 20 ++++++++++++--------\n> 3 files changed, 14 insertions(+), 10 deletions(-)\n>\n> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c\n> index 621b501..d935983 100644\n> --- a/arch/x86/kernel/e820.c\n> +++ b/arch/x86/kernel/e820.c\n> @@ -1188,6 +1188,6 @@ void __init memblock_find_dma_reserve(void)\n> \t\t\tnr_free_pages += end_pfn - start_pfn;\n> \t}\n>\n> -\tset_dma_reserve(nr_pages - nr_free_pages);\n> +\tset_memory_reserve(nr_pages - nr_free_pages, false);\n> #endif\n> }\n> diff --git a/include/linux/mm.h b/include/linux/mm.h\n> index 8f468e0..c884ffb 100644\n> --- a/include/linux/mm.h\n> +++ b/include/linux/mm.h\n> @@ -1886,7 +1886,7 @@ extern int __meminit __early_pfn_to_nid(unsigned long pfn,\n> \t\t\t\t\tstruct mminit_pfnnid_cache *state);\n> #endif\n>\n> -extern void set_dma_reserve(unsigned long new_dma_reserve);\n> +extern void set_memory_reserve(unsigned long nr_reserve, bool inc);\n> extern void memmap_init_zone(unsigned long, int, unsigned long,\n> \t\t\t\tunsigned long, enum memmap_context);\n> extern void setup_per_zone_wmarks(void);\n> diff --git a/mm/page_alloc.c b/mm/page_alloc.c\n> index c1069ef..a154c2f 100644\n> --- a/mm/page_alloc.c\n> +++ b/mm/page_alloc.c\n> @@ -253,7 +253,7 @@ int watermark_scale_factor = 10;\n>\n> static unsigned long __meminitdata nr_kernel_pages;\n> static unsigned long __meminitdata nr_all_pages;\n> -static unsigned long __meminitdata dma_reserve;\n> +static unsigned long __meminitdata nr_memory_reserve;\n>\n> #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP\n> static unsigned long __meminitdata arch_zone_lowest_possible_pfn[MAX_NR_ZONES];\n> @@ -5493,10 +5493,10 @@ static void __paginginit free_area_init_core(struct pglist_data *pgdat)\n> \t\t}\n>\n> \t\t/* Account for reserved pages */\n> -\t\tif (j == 0 && freesize > dma_reserve) {\n> -\t\t\tfreesize -= dma_reserve;\n> +\t\tif (j == 0 && freesize > nr_memory_reserve) {\n\nWill this really work (together with patch 2) as intended?\nThis j == 0 means that we are doing this only for the first zone, which \nis ZONE_DMA (or ZONE_DMA32) on node 0 on many systems. I.e. I don't \nthink it's really true that \"dma_reserve has nothing to do with DMA or \nZONE_DMA\".\n\nThis zone will have limited amount of memory, so the \"freesize > \nnr_memory_reserve\" will easily be false once you set this to many \ngigabytes, so in fact nothing will get subtracted.\n\nOn the other hand if the kernel has both CONFIG_ZONE_DMA and \nCONFIG_ZONE_DMA32 disabled, then j == 0 will be true for ZONE_NORMAL. \nThis zone might be present on multiple nodes (unless they are configured \nas movable) and then the value intended to be global will be subtracted \nfrom several nodes.\n\nI don't know what's the exact ppc64 situation here, perhaps there are \nindeed no DMA/DMA32 zones, and the fadump kernel only uses one node, so \nit works in the end, but it doesn't seem much robust to me?\n\n> +\t\t\tfreesize -= nr_memory_reserve;\n> \t\t\tprintk(KERN_DEBUG \" %s zone: %lu pages reserved\\n\",\n> -\t\t\t\t\tzone_names[0], dma_reserve);\n> +\t\t\t\t\tzone_names[0], nr_memory_reserve);\n> \t\t}\n>\n> \t\tif (!is_highmem_idx(j))\n> @@ -6186,8 +6186,9 @@ void __init mem_init_print_info(const char *str)\n> }\n>\n> /**\n> - * set_dma_reserve - set the specified number of pages reserved in the first zone\n> - * @new_dma_reserve: The number of pages to mark reserved\n> + * set_memory_reserve - set number of pages reserved in the first zone\n> + * @nr_reserve: The number of pages to mark reserved\n> + * @inc: true increment to existing value; false set new value.\n> *\n> * The per-cpu batchsize and zone watermarks are determined by managed_pages.\n> * In the DMA zone, a significant percentage may be consumed by kernel image\n> @@ -6196,9 +6197,12 @@ void __init mem_init_print_info(const char *str)\n> * first zone (e.g., ZONE_DMA). The effect will be lower watermarks and\n> * smaller per-cpu batchsize.\n> */\n> -void __init set_dma_reserve(unsigned long new_dma_reserve)\n> +void __init set_memory_reserve(unsigned long nr_reserve, bool inc)\n> {\n> -\tdma_reserve = new_dma_reserve;\n> +\tif (inc)\n> +\t\tnr_memory_reserve += nr_reserve;\n> +\telse\n> +\t\tnr_memory_reserve = nr_reserve;\n> }\n>\n> void __init free_area_init(unsigned long *zones_size)\n>","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3s5HQ85gLjz9t0F\n\tfor ;\n\tFri, 5 Aug 2016 16:46:08 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s5HQ84ntqzDqYR\n\tfor ;\n\tFri, 5 Aug 2016 16:46:08 +1000 (AEST)","from mx2.suse.de (mx2.suse.de [195.135.220.15])\n\t(using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3s5HP22yBnzDqQ1\n\tfor ;\n\tFri, 5 Aug 2016 16:45:09 +1000 (AEST)","from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])\n\tby mx2.suse.de (Postfix) with ESMTP id 8CF4FAAD1;\n\tFri, 5 Aug 2016 06:45:05 +0000 (UTC)"],"X-Virus-Scanned":"by amavisd-new at test-mx.suse.de","Subject":"Re: [PATCH V2 1/2] mm/page_alloc: Replace set_dma_reserve to\n\tset_memory_reserve","To":"Srikar Dronamraju , linux-mm@kvack.org,\n\tMel Gorman ,\n\tMichal Hocko , \n\tAndrew Morton ,\n\tMichael Ellerman , linuxppc-dev@lists.ozlabs.org, \n\tMahesh Salgaonkar ,\n\tHari Bathini ","References":"<1470330729-6273-1-git-send-email-srikar@linux.vnet.ibm.com>","From":"Vlastimil Babka ","Message-ID":"<09d5b30e-5956-bf64-5f4c-ea5425d7f7a5@suse.cz>","Date":"Fri, 5 Aug 2016 08:45:03 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.2","MIME-Version":"1.0","In-Reply-To":"<1470330729-6273-1-git-send-email-srikar@linux.vnet.ibm.com>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"7bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.22","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dave Hansen ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1424262,"web_url":"http://patchwork.ozlabs.org/comment/1424262/","msgid":"<20160805064747.GN2799@techsingularity.net>","date":"2016-08-05T06:47:47","subject":"Re: [PATCH V2 1/2] mm/page_alloc: Replace set_dma_reserve to\n\tset_memory_reserve","submitter":{"id":67639,"url":"http://patchwork.ozlabs.org/api/people/67639/","name":"Mel Gorman","email":"mgorman@techsingularity.net"},"content":"On Thu, Aug 04, 2016 at 10:42:08PM +0530, Srikar Dronamraju wrote:\n> Expand the scope of the existing dma_reserve to accommodate other memory\n> reserves too. Accordingly rename variable dma_reserve to\n> nr_memory_reserve.\n> \n> set_memory_reserve also takes a new parameter that helps to identify if\n> the current value needs to be incremented.\n> \n\nI think the parameter is ugly and it should have been just\ninc_memory_reserve but at least it works.","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3s5HTR09lqz9t0J\n\tfor ;\n\tFri, 5 Aug 2016 16:48:59 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s5HTQ6VqmzDrP8\n\tfor ;\n\tFri, 5 Aug 2016 16:48:58 +1000 (AEST)","from outbound-smtp08.blacknight.com (outbound-smtp08.blacknight.com\n\t[46.22.139.13])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3s5HSB1y1SzDqQq\n\tfor ;\n\tFri, 5 Aug 2016 16:47:53 +1000 (AEST)","from mail.blacknight.com (pemlinmail05.blacknight.ie\n\t[81.17.254.26])\n\tby outbound-smtp08.blacknight.com (Postfix) with ESMTPS id\n\t950471C1AE5 for ;\n\tFri, 5 Aug 2016 07:47:49 +0100 (IST)","(qmail 24641 invoked from network); 5 Aug 2016 06:47:49 -0000","from unknown (HELO techsingularity.net)\n\t(mgorman@techsingularity.net@[37.228.231.136])\n\tby 81.17.254.9 with ESMTPSA (DHE-RSA-AES256-SHA encrypted,\n\tauthenticated); 5 Aug 2016 06:47:49 -0000"],"Date":"Fri, 5 Aug 2016 07:47:47 +0100","From":"Mel Gorman ","To":"Srikar Dronamraju ","Subject":"Re: [PATCH V2 1/2] mm/page_alloc: Replace set_dma_reserve to\n\tset_memory_reserve","Message-ID":"<20160805064747.GN2799@techsingularity.net>","References":"<1470330729-6273-1-git-send-email-srikar@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-15","Content-Disposition":"inline","In-Reply-To":"<1470330729-6273-1-git-send-email-srikar@linux.vnet.ibm.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.22","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dave Hansen , Michal Hocko ,\n\tlinux-mm@kvack.org, Mahesh Salgaonkar ,\n\tHari Bathini ,\n\tAndrew Morton ,\n\tlinuxppc-dev@lists.ozlabs.org, Vlastimil Babka ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1424292,"web_url":"http://patchwork.ozlabs.org/comment/1424292/","msgid":"<20160805072450.GE11268@linux.vnet.ibm.com>","date":"2016-08-05T07:24:50","subject":"Re: [PATCH V2 1/2] mm/page_alloc: Replace set_dma_reserve to\n\tset_memory_reserve","submitter":{"id":11795,"url":"http://patchwork.ozlabs.org/api/people/11795/","name":"Srikar Dronamraju","email":"srikar@linux.vnet.ibm.com"},"content":"* Vlastimil Babka [2016-08-05 08:45:03]:\n\n> >@@ -5493,10 +5493,10 @@ static void __paginginit free_area_init_core(struct pglist_data *pgdat)\n> > \t\t}\n> >\n> > \t\t/* Account for reserved pages */\n> >-\t\tif (j == 0 && freesize > dma_reserve) {\n> >-\t\t\tfreesize -= dma_reserve;\n> >+\t\tif (j == 0 && freesize > nr_memory_reserve) {\n> \n> Will this really work (together with patch 2) as intended?\n> This j == 0 means that we are doing this only for the first zone, which is\n> ZONE_DMA (or ZONE_DMA32) on node 0 on many systems. I.e. I don't think it's\n> really true that \"dma_reserve has nothing to do with DMA or ZONE_DMA\".\n> \n> This zone will have limited amount of memory, so the \"freesize >\n> nr_memory_reserve\" will easily be false once you set this to many gigabytes,\n> so in fact nothing will get subtracted.\n> \n> On the other hand if the kernel has both CONFIG_ZONE_DMA and\n> CONFIG_ZONE_DMA32 disabled, then j == 0 will be true for ZONE_NORMAL. This\n> zone might be present on multiple nodes (unless they are configured as\n> movable) and then the value intended to be global will be subtracted from\n> several nodes.\n> \n> I don't know what's the exact ppc64 situation here, perhaps there are indeed\n> no DMA/DMA32 zones, and the fadump kernel only uses one node, so it works in\n> the end, but it doesn't seem much robust to me?\n> \n\nAt the page initialization time, powerpc seems to have just one zone\nspread across the 16 nodes.\n\nFrom the dmesg.\n\n[ 0.000000] Memory hole size: 0MB\n[ 0.000000] Zone ranges:\n[ 0.000000] DMA [mem 0x0000000000000000-0x00001f5c8fffffff]\n[ 0.000000] DMA32 empty\n[ 0.000000] Normal empty\n[ 0.000000] Movable zone start for each node\n[ 0.000000] Early memory node ranges\n[ 0.000000] node 0: [mem 0x0000000000000000-0x000001fb4fffffff]\n[ 0.000000] node 1: [mem 0x000001fb50000000-0x000003fa8fffffff]\n[ 0.000000] node 2: [mem 0x000003fa90000000-0x000005f9cfffffff]\n[ 0.000000] node 3: [mem 0x000005f9d0000000-0x000007f8efffffff]\n[ 0.000000] node 4: [mem 0x000007f8f0000000-0x000009f81fffffff]\n[ 0.000000] node 5: [mem 0x000009f820000000-0x00000bf77fffffff]\n[ 0.000000] node 6: [mem 0x00000bf780000000-0x00000df6dfffffff]\n[ 0.000000] node 7: [mem 0x00000df6e0000000-0x00000ff63fffffff]\n[ 0.000000] node 8: [mem 0x00000ff640000000-0x000011f58fffffff]\n[ 0.000000] node 9: [mem 0x000011f590000000-0x000013644fffffff]\n[ 0.000000] node 10: [mem 0x0000136450000000-0x00001563afffffff]\n[ 0.000000] node 11: [mem 0x00001563b0000000-0x000017630fffffff]\n[ 0.000000] node 12: [mem 0x0000176310000000-0x000019625fffffff]\n[ 0.000000] node 13: [mem 0x0000196260000000-0x00001b5dcfffffff]\n[ 0.000000] node 14: [mem 0x00001b5dd0000000-0x00001d5d2fffffff]\n[ 0.000000] node 15: [mem 0x00001d5d30000000-0x00001f5c8fffffff]\n\n\nThe config has the below.\n\nCONFIG_ZONE_DMA32=y\nCONFIG_HIGH_RES_TIMERS=y\nCONFIG_ZONE_DMA_FLAG=1\nCONFIG_FORCE_MAX_ZONEORDER=9\nCONFIG_ZONE_DMA=y\n\nI tried forcing CONFIG_ZONE_DMA to be not set, but make always pick it.\nFrom source arch/powerpc/Kconfig marks CONFIG_ZONE_DMA as \"default y\"","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3s5JJJ0Lglz9t0X\n\tfor ;\n\tFri, 5 Aug 2016 17:26:08 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s5JJH25tVzDqVH\n\tfor ;\n\tFri, 5 Aug 2016 17:26:07 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3s5JH22W1GzDqPn\n\tfor ;\n\tFri, 5 Aug 2016 17:25:02 +1000 (AEST)","from pps.filterd (m0098394.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id\n\tu757JZSt012031\n\tfor ; Fri, 5 Aug 2016 03:25:00 -0400","from e28smtp02.in.ibm.com (e28smtp02.in.ibm.com [125.16.236.2])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 24kkakhg64-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 05 Aug 2016 03:24:59 -0400","from localhost\n\tby e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ; \n\tFri, 5 Aug 2016 12:54:56 +0530","from d28dlp01.in.ibm.com (9.184.220.126)\n\tby e28smtp02.in.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tFri, 5 Aug 2016 12:54:54 +0530","from d28relay07.in.ibm.com (d28relay07.in.ibm.com [9.184.220.158])\n\tby d28dlp01.in.ibm.com (Postfix) with ESMTP id DDDCDE005A\n\tfor ;\n\tFri, 5 Aug 2016 12:59:15 +0530 (IST)","from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])\n\tby d28relay07.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tu757OrZP36372720\n\tfor ; Fri, 5 Aug 2016 12:54:53 +0530","from d28av01.in.ibm.com (localhost [127.0.0.1])\n\tby d28av01.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tu757Opxi028688\n\tfor ; Fri, 5 Aug 2016 12:54:53 +0530","from linux.vnet.ibm.com (srdronam.in.ibm.com [9.124.31.34])\n\tby d28av01.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id\n\tu757OodM028675; Fri, 5 Aug 2016 12:54:50 +0530"],"X-IBM-Helo":"d28dlp01.in.ibm.com","X-IBM-MailFrom":"srikar@linux.vnet.ibm.com","X-IBM-RcptTo":"linuxppc-dev@lists.ozlabs.org","Date":"Fri, 5 Aug 2016 12:54:50 +0530","From":"Srikar Dronamraju ","To":"Vlastimil Babka ","Subject":"Re: [PATCH V2 1/2] mm/page_alloc: Replace set_dma_reserve to\n\tset_memory_reserve","References":"<1470330729-6273-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<09d5b30e-5956-bf64-5f4c-ea5425d7f7a5@suse.cz>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<09d5b30e-5956-bf64-5f4c-ea5425d7f7a5@suse.cz>","User-Agent":"Mutt/1.5.23 (2014-03-12)","X-TM-AS-MML":"disable","x-cbid":"16080507-0004-0000-0000-000002E37721","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"16080507-0005-0000-0000-00000E725C8A","Message-Id":"<20160805072450.GE11268@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2016-08-05_05:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=2\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000\n\tdefinitions=main-1608050096","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.22","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"Srikar Dronamraju ","Cc":"Dave Hansen ,\n\tMel Gorman ,\n\tMichal Hocko , \n\tMahesh Salgaonkar , linux-mm@kvack.org,\n\tHari Bathini ,\n\tAndrew Morton , linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1424303,"web_url":"http://patchwork.ozlabs.org/comment/1424303/","msgid":"<20160805073621.GG11268@linux.vnet.ibm.com>","date":"2016-08-05T07:36:21","subject":"Re: [PATCH V2 1/2] mm/page_alloc: Replace set_dma_reserve to\n\tset_memory_reserve","submitter":{"id":11795,"url":"http://patchwork.ozlabs.org/api/people/11795/","name":"Srikar Dronamraju","email":"srikar@linux.vnet.ibm.com"},"content":"* Mel Gorman [2016-08-05 07:47:47]:\n\n> On Thu, Aug 04, 2016 at 10:42:08PM +0530, Srikar Dronamraju wrote:\n> > Expand the scope of the existing dma_reserve to accommodate other memory\n> > reserves too. Accordingly rename variable dma_reserve to\n> > nr_memory_reserve.\n> > \n> > set_memory_reserve also takes a new parameter that helps to identify if\n> > the current value needs to be incremented.\n> > \n> \n> I think the parameter is ugly and it should have been just\n> inc_memory_reserve but at least it works.\n> \n\nYes while the parameter is definitely ugly, the only other use\ncase in arch/x86/kernel/e820.c seems to be written with an intention to\nset to an absolute value.\n\nIt was \"set_dma_reserve(nr_pages - nr_free_pages)\". Both of them\nnr_pages and nr_free_pages are calculated after walking through the mem\nblocks. I didnt want to take a chance where someother code path also\nstarts to set reserve value and then the code in e820.c just increments\nit.\n\nHowever if you still feel strongly about using inc_memory_reserve than\nset_memory_reserve, I will respin.","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3s5JYR3m9gz9t0F\n\tfor ;\n\tFri, 5 Aug 2016 17:37:31 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s5JYR2kqYzDqYj\n\tfor ;\n\tFri, 5 Aug 2016 17:37:31 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3s5JXK4YTnzDqPn\n\tfor ;\n\tFri, 5 Aug 2016 17:36:33 +1000 (AEST)","from pps.filterd (m0098394.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id\n\tu757XnlI047710\n\tfor ; Fri, 5 Aug 2016 03:36:31 -0400","from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 24kkakhwj9-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 05 Aug 2016 03:36:31 -0400","from localhost\n\tby e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ; \n\tFri, 5 Aug 2016 17:36:28 +1000","from d23dlp01.au.ibm.com (202.81.31.203)\n\tby e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tFri, 5 Aug 2016 17:36:27 +1000","from d23relay06.au.ibm.com (d23relay06.au.ibm.com [9.185.63.219])\n\tby d23dlp01.au.ibm.com (Postfix) with ESMTP id E54E42CE802D\n\tfor ;\n\tFri, 5 Aug 2016 17:36:26 +1000 (EST)","from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])\n\tby d23relay06.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tu757aQVo30802092\n\tfor ; Fri, 5 Aug 2016 17:36:26 +1000","from d23av03.au.ibm.com (localhost [127.0.0.1])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tu757aP4Q011920\n\tfor ; Fri, 5 Aug 2016 17:36:26 +1000","from linux.vnet.ibm.com (srdronam.in.ibm.com [9.124.31.34])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id\n\tu757aMA6011823; Fri, 5 Aug 2016 17:36:22 +1000"],"X-IBM-Helo":"d23dlp01.au.ibm.com","X-IBM-MailFrom":"srikar@linux.vnet.ibm.com","X-IBM-RcptTo":"linuxppc-dev@lists.ozlabs.org","Date":"Fri, 5 Aug 2016 13:06:21 +0530","From":"Srikar Dronamraju ","To":"Mel Gorman ","Subject":"Re: [PATCH V2 1/2] mm/page_alloc: Replace set_dma_reserve to\n\tset_memory_reserve","References":"<1470330729-6273-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<20160805064747.GN2799@techsingularity.net>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<20160805064747.GN2799@techsingularity.net>","User-Agent":"Mutt/1.5.23 (2014-03-12)","X-TM-AS-MML":"disable","X-Content-Scanned":"Fidelis XPS MAILER","x-cbid":"16080507-0048-0000-0000-000001A8E7E9","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"16080507-0049-0000-0000-00004646E7DC","Message-Id":"<20160805073621.GG11268@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2016-08-05_05:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=2\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000\n\tdefinitions=main-1608050098","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.22","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"Srikar Dronamraju ","Cc":"Dave Hansen , Michal Hocko ,\n\tlinux-mm@kvack.org, Mahesh Salgaonkar ,\n\tHari Bathini ,\n\tAndrew Morton ,\n\tlinuxppc-dev@lists.ozlabs.org, Vlastimil Babka ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1424396,"web_url":"http://patchwork.ozlabs.org/comment/1424396/","msgid":"","date":"2016-08-05T09:09:15","subject":"Re: [PATCH V2 1/2] mm/page_alloc: Replace set_dma_reserve to\n\tset_memory_reserve","submitter":{"id":48129,"url":"http://patchwork.ozlabs.org/api/people/48129/","name":"Vlastimil Babka","email":"vbabka@suse.cz"},"content":"On 08/05/2016 09:24 AM, Srikar Dronamraju wrote:\n> * Vlastimil Babka [2016-08-05 08:45:03]:\n>\n>>> @@ -5493,10 +5493,10 @@ static void __paginginit free_area_init_core(struct pglist_data *pgdat)\n>>> \t\t}\n>>>\n>>> \t\t/* Account for reserved pages */\n>>> -\t\tif (j == 0 && freesize > dma_reserve) {\n>>> -\t\t\tfreesize -= dma_reserve;\n>>> +\t\tif (j == 0 && freesize > nr_memory_reserve) {\n>>\n>> Will this really work (together with patch 2) as intended?\n>> This j == 0 means that we are doing this only for the first zone, which is\n>> ZONE_DMA (or ZONE_DMA32) on node 0 on many systems. I.e. I don't think it's\n>> really true that \"dma_reserve has nothing to do with DMA or ZONE_DMA\".\n>>\n>> This zone will have limited amount of memory, so the \"freesize >\n>> nr_memory_reserve\" will easily be false once you set this to many gigabytes,\n>> so in fact nothing will get subtracted.\n>>\n>> On the other hand if the kernel has both CONFIG_ZONE_DMA and\n>> CONFIG_ZONE_DMA32 disabled, then j == 0 will be true for ZONE_NORMAL. This\n>> zone might be present on multiple nodes (unless they are configured as\n>> movable) and then the value intended to be global will be subtracted from\n>> several nodes.\n>>\n>> I don't know what's the exact ppc64 situation here, perhaps there are indeed\n>> no DMA/DMA32 zones, and the fadump kernel only uses one node, so it works in\n>> the end, but it doesn't seem much robust to me?\n>>\n>\n> At the page initialization time, powerpc seems to have just one zone\n> spread across the 16 nodes.\n>\n> From the dmesg.\n>\n> [ 0.000000] Memory hole size: 0MB\n> [ 0.000000] Zone ranges:\n> [ 0.000000] DMA [mem 0x0000000000000000-0x00001f5c8fffffff]\n> [ 0.000000] DMA32 empty\n> [ 0.000000] Normal empty\n> [ 0.000000] Movable zone start for each node\n> [ 0.000000] Early memory node ranges\n> [ 0.000000] node 0: [mem 0x0000000000000000-0x000001fb4fffffff]\n> [ 0.000000] node 1: [mem 0x000001fb50000000-0x000003fa8fffffff]\n> [ 0.000000] node 2: [mem 0x000003fa90000000-0x000005f9cfffffff]\n> [ 0.000000] node 3: [mem 0x000005f9d0000000-0x000007f8efffffff]\n> [ 0.000000] node 4: [mem 0x000007f8f0000000-0x000009f81fffffff]\n> [ 0.000000] node 5: [mem 0x000009f820000000-0x00000bf77fffffff]\n> [ 0.000000] node 6: [mem 0x00000bf780000000-0x00000df6dfffffff]\n> [ 0.000000] node 7: [mem 0x00000df6e0000000-0x00000ff63fffffff]\n> [ 0.000000] node 8: [mem 0x00000ff640000000-0x000011f58fffffff]\n> [ 0.000000] node 9: [mem 0x000011f590000000-0x000013644fffffff]\n> [ 0.000000] node 10: [mem 0x0000136450000000-0x00001563afffffff]\n> [ 0.000000] node 11: [mem 0x00001563b0000000-0x000017630fffffff]\n> [ 0.000000] node 12: [mem 0x0000176310000000-0x000019625fffffff]\n> [ 0.000000] node 13: [mem 0x0000196260000000-0x00001b5dcfffffff]\n> [ 0.000000] node 14: [mem 0x00001b5dd0000000-0x00001d5d2fffffff]\n> [ 0.000000] node 15: [mem 0x00001d5d30000000-0x00001f5c8fffffff]\n\nHmm so it will work for ppc64 and its fadump, but I'm not happy that we \nmade the function name sound like it's generic (unlike when the name \ncontained \"dma\"), while it only works as intended in specific corner \ncases. The next user might be surprised...","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3s5Lcz4Rj0z9sf9\n\tfor ;\n\tFri, 5 Aug 2016 19:10:43 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s5Lcz3hRCzDqdv\n\tfor ;\n\tFri, 5 Aug 2016 19:10:43 +1000 (AEST)","from mx2.suse.de (mx2.suse.de [195.135.220.15])\n\t(using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3s5LbQ40jwzDqQ1\n\tfor ;\n\tFri, 5 Aug 2016 19:09:22 +1000 (AEST)","from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])\n\tby mx2.suse.de (Postfix) with ESMTP id 7B39EAAEF;\n\tFri, 5 Aug 2016 09:09:18 +0000 (UTC)"],"X-Virus-Scanned":"by amavisd-new at test-mx.suse.de","Subject":"Re: [PATCH V2 1/2] mm/page_alloc: Replace set_dma_reserve to\n\tset_memory_reserve","To":"Srikar Dronamraju ","References":"<1470330729-6273-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<09d5b30e-5956-bf64-5f4c-ea5425d7f7a5@suse.cz>\n\t<20160805072450.GE11268@linux.vnet.ibm.com>","From":"Vlastimil Babka ","Message-ID":"","Date":"Fri, 5 Aug 2016 11:09:15 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.2","MIME-Version":"1.0","In-Reply-To":"<20160805072450.GE11268@linux.vnet.ibm.com>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Transfer-Encoding":"7bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.22","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dave Hansen ,\n\tMel Gorman ,\n\tMichal Hocko , \n\tMahesh Salgaonkar , linux-mm@kvack.org,\n\tHari Bathini ,\n\tAndrew Morton , linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}}]