[{"id":1423684,"web_url":"http://patchwork.ozlabs.org/comment/1423684/","msgid":"<20160804140934.GM2799@techsingularity.net>","date":"2016-08-04T14:09:34","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","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 07:12:45PM +0530, Srikar Dronamraju wrote:\n> Fadump kernel reserves large chunks of memory even before the pages are\n> initialized. This could mean memory that corresponds to several nodes might\n> fall in memblock reserved regions.\n> \n> Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialize\n> only certain size memory per node. The certain size takes into account\n> the dentry and inode cache sizes. Currently the cache sizes are\n> calculated based on the total system memory including the reserved\n> memory. However such a kernel when booting the same kernel as fadump\n> kernel will not be able to allocate the required amount of memory to\n> suffice for the dentry and inode caches. This results in crashes like\n> the below on large systems such as 32 TB systems.\n> \n> Dentry cache hash table entries: 536870912 (order: 16, 4294967296 bytes)\n> vmalloc: allocation failure, allocated 4097114112 of 17179934720 bytes\n> swapper/0: page allocation failure: order:0, mode:0x2080020(GFP_ATOMIC)\n> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6-master+ #3\n> Call Trace:\n> [c00000000108fb10] [c0000000007fac88] dump_stack+0xb0/0xf0 (unreliable)\n> [c00000000108fb50] [c000000000235264] warn_alloc_failed+0x114/0x160\n> [c00000000108fbf0] [c000000000281484] __vmalloc_node_range+0x304/0x340\n> [c00000000108fca0] [c00000000028152c] __vmalloc+0x6c/0x90\n> [c00000000108fd40] [c000000000aecfb0]\n> alloc_large_system_hash+0x1b8/0x2c0\n> [c00000000108fe00] [c000000000af7240] inode_init+0x94/0xe4\n> [c00000000108fe80] [c000000000af6fec] vfs_caches_init+0x8c/0x13c\n> [c00000000108ff00] [c000000000ac4014] start_kernel+0x50c/0x578\n> [c00000000108ff90] [c000000000008c6c] start_here_common+0x20/0xa8\n> \n> Register the memory reserved by fadump, so that the cache sizes are\n> calculated based on the free memory (i.e Total memory - reserved\n> memory).\n> \n> Suggested-by: Mel Gorman \n\nI didn't suggest this specifically. While it happens to be safe on ppc64,\nit potentially overwrites any future caller of set_dma_reserve. While the\nonly other one is for the e820 map, it may be better to change the API\nto inc_dma_reserve?\n\nIt's also unfortunate that it's called dma_reserve because it has\nnothing to do with DMA or ZONE_DMA. inc_kernel_reserve may be more\nappropriate?","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 3s4sTy2d12z9sXx\n\tfor ;\n\tFri, 5 Aug 2016 00:17:58 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s4sTy1FmPzDqZk\n\tfor ;\n\tFri, 5 Aug 2016 00:17:58 +1000 (AEST)","from outbound-smtp07.blacknight.com (outbound-smtp07.blacknight.com\n\t[46.22.139.12])\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 3s4sSl0BkLzDqS9\n\tfor ;\n\tFri, 5 Aug 2016 00:16:54 +1000 (AEST)","from mail.blacknight.com (pemlinmail01.blacknight.ie\n\t[81.17.254.10])\n\tby outbound-smtp07.blacknight.com (Postfix) with ESMTPS id\n\t48A941C1A24 for ;\n\tThu, 4 Aug 2016 15:09:36 +0100 (IST)","(qmail 2271 invoked from network); 4 Aug 2016 14:09:36 -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); 4 Aug 2016 14:09:36 -0000"],"X-Greylist":"delayed 433 seconds by postgrey-1.35 at bilbo;\n\tFri, 05 Aug 2016 00:16:55 AEST","Date":"Thu, 4 Aug 2016 15:09:34 +0100","From":"Mel Gorman ","To":"Srikar Dronamraju ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","Message-ID":"<20160804140934.GM2799@techsingularity.net>","References":"<1470318165-2521-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":"<1470318165-2521-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":1423735,"web_url":"http://patchwork.ozlabs.org/comment/1423735/","msgid":"<20160804152743.GD11268@linux.vnet.ibm.com>","date":"2016-08-04T15:27:43","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","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-04 15:09:34]:\n\n> > \n> > Suggested-by: Mel Gorman \n> \n> I didn't suggest this specifically. While it happens to be safe on ppc64,\n> it potentially overwrites any future caller of set_dma_reserve. While the\n> only other one is for the e820 map, it may be better to change the API\n> to inc_dma_reserve?\n> \n> It's also unfortunate that it's called dma_reserve because it has\n> nothing to do with DMA or ZONE_DMA. inc_kernel_reserve may be more\n> appropriate?\n\nYup Agree. Will redo and send out.\n\n> \n> -- \n> Mel Gorman\n> SUSE Labs\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 [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 3s4v3y1p8Tz9sC4\n\tfor ;\n\tFri, 5 Aug 2016 01:29:02 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s4v3y12d2zDqhD\n\tfor ;\n\tFri, 5 Aug 2016 01:29:02 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\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 3s4v2q0zFXzDqS9\n\tfor ;\n\tFri, 5 Aug 2016 01:28:02 +1000 (AEST)","from pps.filterd (m0098417.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id\n\tu74FO1XO017016\n\tfor ; Thu, 4 Aug 2016 11:28:00 -0400","from e28smtp02.in.ibm.com (e28smtp02.in.ibm.com [125.16.236.2])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 24kkakb6gj-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 04 Aug 2016 11:27: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\tThu, 4 Aug 2016 20:57: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\tThu, 4 Aug 2016 20:57:52 +0530","from d28relay06.in.ibm.com (d28relay06.in.ibm.com [9.184.220.150])\n\tby d28dlp01.in.ibm.com (Postfix) with ESMTP id D9BAEE005B\n\tfor ;\n\tThu, 4 Aug 2016 21:02:12 +0530 (IST)","from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])\n\tby d28relay06.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tu74FRp0O49152036\n\tfor ; Thu, 4 Aug 2016 20:57:51 +0530","from d28av02.in.ibm.com (localhost [127.0.0.1])\n\tby d28av02.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tu74FRkeE008845\n\tfor ; Thu, 4 Aug 2016 20:57:50 +0530","from linux.vnet.ibm.com (srdronam.in.ibm.com [9.124.31.34])\n\tby d28av02.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id\n\tu74FRh7c008775; Thu, 4 Aug 2016 20:57:43 +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":"Thu, 4 Aug 2016 20:57:43 +0530","From":"Srikar Dronamraju ","To":"Mel Gorman ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","References":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<20160804140934.GM2799@techsingularity.net>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<20160804140934.GM2799@techsingularity.net>","User-Agent":"Mutt/1.5.23 (2014-03-12)","X-TM-AS-MML":"disable","X-Content-Scanned":"Fidelis XPS MAILER","x-cbid":"16080415-0004-0000-0000-000002E2B3D0","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"16080415-0005-0000-0000-00000E6F727B","Message-Id":"<20160804152743.GD11268@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2016-08-04_09:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\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-1608040169","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":1424277,"web_url":"http://patchwork.ozlabs.org/comment/1424277/","msgid":"<87mvkritii.fsf@concordia.ellerman.id.au>","date":"2016-08-05T07:07:01","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Srikar Dronamraju writes:\n\n> Fadump kernel reserves large chunks of memory even before the pages are\n> initialized. This could mean memory that corresponds to several nodes might\n> fall in memblock reserved regions.\n>\n...\n> Register the memory reserved by fadump, so that the cache sizes are\n> calculated based on the free memory (i.e Total memory - reserved\n> memory).\n\nThe memory is reserved, with memblock_reserve(). Why is that not sufficient?\n\ncheers","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 3s5HvK5gC2z9svs\n\tfor ;\n\tFri, 5 Aug 2016 17:07:57 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s5HvK4vdNzDqTt\n\tfor ;\n\tFri, 5 Aug 2016 17:07:57 +1000 (AEST)","from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2])\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 3s5HtF3x3DzDqQ1\n\tfor ;\n\tFri, 5 Aug 2016 17:07:01 +1000 (AEST)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3s5HtF27Smz9t0F;\n\tFri, 5 Aug 2016 17:07:01 +1000 (AEST)"],"From":"Michael Ellerman ","To":"Srikar Dronamraju , linux-mm@kvack.org,\n\tMel Gorman ,\n\tVlastimil Babka , Michal Hocko ,\n\tAndrew Morton , \n\tlinuxppc-dev@lists.ozlabs.org,\n\tMahesh Salgaonkar , \n\tHari Bathini ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","In-Reply-To":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>","References":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>","User-Agent":"Notmuch/0.21 (https://notmuchmail.org)","Date":"Fri, 05 Aug 2016 17:07:01 +1000","Message-ID":"<87mvkritii.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","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\tSrikar Dronamraju ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1424297,"web_url":"http://patchwork.ozlabs.org/comment/1424297/","msgid":"<20160805072838.GF11268@linux.vnet.ibm.com>","date":"2016-08-05T07:28:38","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","submitter":{"id":11795,"url":"http://patchwork.ozlabs.org/api/people/11795/","name":"Srikar Dronamraju","email":"srikar@linux.vnet.ibm.com"},"content":"* Michael Ellerman [2016-08-05 17:07:01]:\n\n> Srikar Dronamraju writes:\n> \n> > Fadump kernel reserves large chunks of memory even before the pages are\n> > initialized. This could mean memory that corresponds to several nodes might\n> > fall in memblock reserved regions.\n> >\n> ...\n> > Register the memory reserved by fadump, so that the cache sizes are\n> > calculated based on the free memory (i.e Total memory - reserved\n> > memory).\n> \n> The memory is reserved, with memblock_reserve(). Why is that not sufficient?\n> \n> cheers\n> \n\nBecause at page initialization time, the kernel doesnt know how many\npages are reserved. One way to do that would be to walk through the\ndifferent memory reserved blocks and calculate the size. But Mel feels\nthats an overhead (from his reply to the other thread) esp for just one\nuse case.","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 3s5JNX68bVz9t1G\n\tfor ;\n\tFri, 5 Aug 2016 17:29:48 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s5JNX5P1QzDqZW\n\tfor ;\n\tFri, 5 Aug 2016 17:29:48 +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 3s5JMT3RFjzDqPn\n\tfor ;\n\tFri, 5 Aug 2016 17:28:53 +1000 (AEST)","from pps.filterd (m0098396.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id\n\tu757PZIx128006\n\tfor ; Fri, 5 Aug 2016 03:28:51 -0400","from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 24kkajhh4f-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 05 Aug 2016 03:28:51 -0400","from localhost\n\tby e23smtp03.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:28:48 +1000","from d23dlp03.au.ibm.com (202.81.31.214)\n\tby e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tFri, 5 Aug 2016 17:28:46 +1000","from d23relay09.au.ibm.com (d23relay09.au.ibm.com [9.185.63.181])\n\tby d23dlp03.au.ibm.com (Postfix) with ESMTP id 09DF2357805D\n\tfor ;\n\tFri, 5 Aug 2016 17:28:46 +1000 (EST)","from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])\n\tby d23relay09.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tu757SjA226673326\n\tfor ; Fri, 5 Aug 2016 17:28:45 +1000","from d23av04.au.ibm.com (localhost [127.0.0.1])\n\tby d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tu757ShSg026235\n\tfor ; Fri, 5 Aug 2016 17:28:45 +1000","from linux.vnet.ibm.com (srdronam.in.ibm.com [9.124.31.34])\n\tby d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id\n\tu757Sd13025978; Fri, 5 Aug 2016 17:28:40 +1000"],"X-IBM-Helo":"d23dlp03.au.ibm.com","X-IBM-MailFrom":"srikar@linux.vnet.ibm.com","X-IBM-RcptTo":"linuxppc-dev@lists.ozlabs.org","Date":"Fri, 5 Aug 2016 12:58:38 +0530","From":"Srikar Dronamraju ","To":"Michael Ellerman ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","References":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<87mvkritii.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<87mvkritii.fsf@concordia.ellerman.id.au>","User-Agent":"Mutt/1.5.23 (2014-03-12)","X-TM-AS-MML":"disable","X-Content-Scanned":"Fidelis XPS MAILER","x-cbid":"16080507-0008-0000-0000-000000AD729A","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"16080507-0009-0000-0000-000007CAE1A8","Message-Id":"<20160805072838.GF11268@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=0\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-1608050097","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 , linuxppc-dev@lists.ozlabs.org,\n\tMichal Hocko , linux-mm@kvack.org,\n\tMahesh Salgaonkar ,\n\tHari Bathini ,\n\tAndrew Morton ,\n\tMel Gorman ,\n\tVlastimil Babka ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1424413,"web_url":"http://patchwork.ozlabs.org/comment/1424413/","msgid":"<87h9azin4g.fsf@concordia.ellerman.id.au>","date":"2016-08-05T09:25:03","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Srikar Dronamraju writes:\n\n> * Michael Ellerman [2016-08-05 17:07:01]:\n>\n>> Srikar Dronamraju writes:\n>> \n>> > Fadump kernel reserves large chunks of memory even before the pages are\n>> > initialized. This could mean memory that corresponds to several nodes might\n>> > fall in memblock reserved regions.\n>> >\n>> ...\n>> > Register the memory reserved by fadump, so that the cache sizes are\n>> > calculated based on the free memory (i.e Total memory - reserved\n>> > memory).\n>> \n>> The memory is reserved, with memblock_reserve(). Why is that not sufficient?\n>\n> Because at page initialization time, the kernel doesnt know how many\n> pages are reserved.\n\nThe kernel does know, the fadump code that does the memblock reserve\nruns before start_kernel(). AFAIK all calls to alloc_large_system_hash()\nare after that.\n\nSo the problem seems to be just that alloc_large_system_hash() doesn't\nknow about reserved memory.\n\n> One way to do that would be to walk through the different memory\n> reserved blocks and calculate the size. But Mel feels thats an\n> overhead (from his reply to the other thread) esp for just one use\n> case.\n\nOK. I think you're referring to this:\n\n If fadump is reserving memory and alloc_large_system_hash(HASH_EARLY)\n does not know about then then would an arch-specific callback for\n arch_reserved_kernel_pages() be more appropriate?\n ...\n \n That approach would limit the impact to ppc64 and would be less costly than\n doing a memblock walk instead of using nr_kernel_pages for everyone else.\n\nThat sounds more robust to me than this solution.\n\ncheers","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 3s5Lyl1WJrz9t1P\n\tfor ;\n\tFri, 5 Aug 2016 19:26:07 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s5Lyl0jGdzDqgw\n\tfor ;\n\tFri, 5 Aug 2016 19:26:07 +1000 (AEST)","from ozlabs.org (ozlabs.org [103.22.144.67])\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 3s5Lxd1FQDzDqQ1\n\tfor ;\n\tFri, 5 Aug 2016 19:25:09 +1000 (AEST)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3s5Lxc6nHRz9snm;\n\tFri, 5 Aug 2016 19:25:08 +1000 (AEST)"],"From":"Michael Ellerman ","To":"Srikar Dronamraju ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","In-Reply-To":"<20160805072838.GF11268@linux.vnet.ibm.com>","References":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<87mvkritii.fsf@concordia.ellerman.id.au>\n\t<20160805072838.GF11268@linux.vnet.ibm.com>","User-Agent":"Notmuch/0.21 (https://notmuchmail.org)","Date":"Fri, 05 Aug 2016 19:25:03 +1000","Message-ID":"<87h9azin4g.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","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 , linuxppc-dev@lists.ozlabs.org,\n\tMichal Hocko , linux-mm@kvack.org,\n\tMahesh Salgaonkar ,\n\tHari Bathini ,\n\tAndrew Morton ,\n\tMel Gorman ,\n\tVlastimil Babka ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1424461,"web_url":"http://patchwork.ozlabs.org/comment/1424461/","msgid":"<20160805100609.GP2799@techsingularity.net>","date":"2016-08-05T10:06:09","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","submitter":{"id":67639,"url":"http://patchwork.ozlabs.org/api/people/67639/","name":"Mel Gorman","email":"mgorman@techsingularity.net"},"content":"On Fri, Aug 05, 2016 at 07:25:03PM +1000, Michael Ellerman wrote:\n> > One way to do that would be to walk through the different memory\n> > reserved blocks and calculate the size. But Mel feels thats an\n> > overhead (from his reply to the other thread) esp for just one use\n> > case.\n> \n> OK. I think you're referring to this:\n> \n> If fadump is reserving memory and alloc_large_system_hash(HASH_EARLY)\n> does not know about then then would an arch-specific callback for\n> arch_reserved_kernel_pages() be more appropriate?\n> ...\n> \n> That approach would limit the impact to ppc64 and would be less costly than\n> doing a memblock walk instead of using nr_kernel_pages for everyone else.\n> \n> That sounds more robust to me than this solution.\n> \n\nIt would be the fastest with the least impact but not necessarily the\nbest. Ultimately that dma_reserve/memory_reserve is used for the sizing\ncalculation of the large system hashes but only the e820 map and fadump\nis taken into account. That's a bit filthy even if it happens to work out ok.\n\nConceptually it would be cleaner, if expensive, to calculate the real\nmemblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve\nand nr_kernel_pages entirely. Unfortuantely, aside from the calculation,\nthere is a potential cost due to a smaller hash table that affects everyone,\nnot just ppc64. However, if the hash table is meant to be sized on the\nnumber of available pages then it really should be based on that and not\njust a made-up number.","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 3s5N2b2DKpz9ssM\n\tfor ;\n\tFri, 5 Aug 2016 20:14:31 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s5N2b1TQwzDrFY\n\tfor ;\n\tFri, 5 Aug 2016 20:14:31 +1000 (AEST)","from outbound-smtp05.blacknight.com (outbound-smtp05.blacknight.com\n\t[81.17.249.38])\n\t(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3s5N1Q4Fx0zDqV6\n\tfor ;\n\tFri, 5 Aug 2016 20:13:30 +1000 (AEST)","from mail.blacknight.com (pemlinmail03.blacknight.ie\n\t[81.17.254.16])\n\tby outbound-smtp05.blacknight.com (Postfix) with ESMTPS id EFD5A98DD0\n\tfor ;\n\tFri, 5 Aug 2016 10:06:10 +0000 (UTC)","(qmail 18203 invoked from network); 5 Aug 2016 10:06:10 -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 10:06:10 -0000"],"X-Greylist":"delayed 430 seconds by postgrey-1.35 at bilbo;\n\tFri, 05 Aug 2016 20:13:30 AEST","Date":"Fri, 5 Aug 2016 11:06:09 +0100","From":"Mel Gorman ","To":"Michael Ellerman ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","Message-ID":"<20160805100609.GP2799@techsingularity.net>","References":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<87mvkritii.fsf@concordia.ellerman.id.au>\n\t<20160805072838.GF11268@linux.vnet.ibm.com>\n\t<87h9azin4g.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-15","Content-Disposition":"inline","In-Reply-To":"<87h9azin4g.fsf@concordia.ellerman.id.au>","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":"Srikar Dronamraju ,\n\tDave Hansen ,\n\tMahesh Salgaonkar ,\n\tMichal Hocko , linux-mm@kvack.org,\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":1427704,"web_url":"http://patchwork.ozlabs.org/comment/1427704/","msgid":"<87d1lhtb3s.fsf@concordia.ellerman.id.au>","date":"2016-08-10T06:02:47","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Mel Gorman writes:\n\n> On Fri, Aug 05, 2016 at 07:25:03PM +1000, Michael Ellerman wrote:\n>> > One way to do that would be to walk through the different memory\n>> > reserved blocks and calculate the size. But Mel feels thats an\n>> > overhead (from his reply to the other thread) esp for just one use\n>> > case.\n>> \n>> OK. I think you're referring to this:\n>> \n>> If fadump is reserving memory and alloc_large_system_hash(HASH_EARLY)\n>> does not know about then then would an arch-specific callback for\n>> arch_reserved_kernel_pages() be more appropriate?\n>> ...\n>> \n>> That approach would limit the impact to ppc64 and would be less costly than\n>> doing a memblock walk instead of using nr_kernel_pages for everyone else.\n>> \n>> That sounds more robust to me than this solution.\n>\n> It would be the fastest with the least impact but not necessarily the\n> best. Ultimately that dma_reserve/memory_reserve is used for the sizing\n> calculation of the large system hashes but only the e820 map and fadump\n> is taken into account. That's a bit filthy even if it happens to work out ok.\n\nRight.\n\n> Conceptually it would be cleaner, if expensive, to calculate the real\n> memblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve\n> and nr_kernel_pages entirely.\n\nWhy is it expensive? memblock tracks the totals for all memory and\nreserved memory AFAIK, so it should just be a case of subtracting one\nfrom the other?\n\n> Unfortuantely, aside from the calculation,\n> there is a potential cost due to a smaller hash table that affects everyone,\n> not just ppc64.\n\nYeah OK. We could make it an arch hook, or controlled by a CONFIG.\n\n> However, if the hash table is meant to be sized on the\n> number of available pages then it really should be based on that and not\n> just a made-up number.\n\nYeah that seems to make sense.\n\nThe one complication I think is that we may have memory that's marked\nreserved in memblock, but is later freed to the page allocator (eg.\ninitrd).\n\nI'm not sure if that's actually a concern in practice given the relative\nsize of the initrd and memory on most systems. But possibly there are\nother things that get reserved and then freed which could skew the hash\ntable size calculation.\n\ncheers","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 3s8LDy6c83z9stc\n\tfor ;\n\tWed, 10 Aug 2016 16:03:46 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s8LDy5BS5zDr4D\n\tfor ;\n\tWed, 10 Aug 2016 16:03:46 +1000 (AEST)","from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2])\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 3s8LCw0FDRzDqRR\n\tfor ;\n\tWed, 10 Aug 2016 16:02:52 +1000 (AEST)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3s8LCv65bvz9stc;\n\tWed, 10 Aug 2016 16:02:51 +1000 (AEST)"],"From":"Michael Ellerman ","To":"Mel Gorman ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","In-Reply-To":"<20160805100609.GP2799@techsingularity.net>","References":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<87mvkritii.fsf@concordia.ellerman.id.au>\n\t<20160805072838.GF11268@linux.vnet.ibm.com>\n\t<87h9azin4g.fsf@concordia.ellerman.id.au>\n\t<20160805100609.GP2799@techsingularity.net>","User-Agent":"Notmuch/0.21 (https://notmuchmail.org)","Date":"Wed, 10 Aug 2016 16:02:47 +1000","Message-ID":"<87d1lhtb3s.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","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":"Srikar Dronamraju ,\n\tDave Hansen ,\n\tMahesh Salgaonkar ,\n\tMichal Hocko , linux-mm@kvack.org,\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":1427714,"web_url":"http://patchwork.ozlabs.org/comment/1427714/","msgid":"<20160810064056.GB24800@linux.vnet.ibm.com>","date":"2016-08-10T06:40:56","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","submitter":{"id":11795,"url":"http://patchwork.ozlabs.org/api/people/11795/","name":"Srikar Dronamraju","email":"srikar@linux.vnet.ibm.com"},"content":"> \n> > Conceptually it would be cleaner, if expensive, to calculate the real\n> > memblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve\n> > and nr_kernel_pages entirely.\n> \n> Why is it expensive? memblock tracks the totals for all memory and\n> reserved memory AFAIK, so it should just be a case of subtracting one\n> from the other?\n\nAre you suggesting that we use something like\nmemblock_phys_mem_size() but one which returns\nmemblock.reserved.total_size ? Maybe a new function like\nmemblock_reserved_mem_size()?\n\n> \n> > Unfortuantely, aside from the calculation,\n> > there is a potential cost due to a smaller hash table that affects everyone,\n> > not just ppc64.\n> \n> Yeah OK. We could make it an arch hook, or controlled by a CONFIG.\n\nIf its based on memblock.reserved.total_size, then should it be arch\nspecific?\n\n> \n> > However, if the hash table is meant to be sized on the\n> > number of available pages then it really should be based on that and not\n> > just a made-up number.\n> \n> Yeah that seems to make sense.\n> \n> The one complication I think is that we may have memory that's marked\n> reserved in memblock, but is later freed to the page allocator (eg.\n> initrd).\n\nYes, this is a possibility, for example lets say we want fadump to\ncontinue to run instead of rebooting to a new kernel as it does today.\n\n> \n> I'm not sure if that's actually a concern in practice given the relative\n> size of the initrd and memory on most systems. But possibly there are\n> other things that get reserved and then freed which could skew the hash\n> table size calculation.\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 [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 3s8M595nHbz9syB\n\tfor ;\n\tWed, 10 Aug 2016 16:42:05 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s8M5952bZzDqwH\n\tfor ;\n\tWed, 10 Aug 2016 16:42:05 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\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 3s8M452w9czDqRR\n\tfor ;\n\tWed, 10 Aug 2016 16:41:09 +1000 (AEST)","from pps.filterd (m0098416.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id\n\tu7A6d4Ve027933\n\tfor ; Wed, 10 Aug 2016 02:41:06 -0400","from e23smtp07.au.ibm.com (e23smtp07.au.ibm.com [202.81.31.140])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 24qm9q6de5-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 10 Aug 2016 02:41:06 -0400","from localhost\n\tby e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ; \n\tWed, 10 Aug 2016 16:41:03 +1000","from d23dlp03.au.ibm.com (202.81.31.214)\n\tby e23smtp07.au.ibm.com (202.81.31.204) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 10 Aug 2016 16:41:01 +1000","from d23relay09.au.ibm.com (d23relay09.au.ibm.com [9.185.63.181])\n\tby d23dlp03.au.ibm.com (Postfix) with ESMTP id 4162D3578052\n\tfor ;\n\tWed, 10 Aug 2016 16:41:01 +1000 (EST)","from d23av06.au.ibm.com (d23av06.au.ibm.com [9.190.235.151])\n\tby d23relay09.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tu7A6f1cQ15335646\n\tfor ; Wed, 10 Aug 2016 16:41:01 +1000","from d23av06.au.ibm.com (localhost [127.0.0.1])\n\tby d23av06.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tu7A6excM011898\n\tfor ; Wed, 10 Aug 2016 16:41:00 +1000","from linux.vnet.ibm.com (srdronam.in.ibm.com [9.124.31.34])\n\tby d23av06.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id\n\tu7A6eu8D011783; Wed, 10 Aug 2016 16:40:57 +1000"],"X-IBM-Helo":"d23dlp03.au.ibm.com","X-IBM-MailFrom":"srikar@linux.vnet.ibm.com","X-IBM-RcptTo":"linuxppc-dev@lists.ozlabs.org","Date":"Wed, 10 Aug 2016 12:10:56 +0530","From":"Srikar Dronamraju ","To":"Michael Ellerman ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","References":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<87mvkritii.fsf@concordia.ellerman.id.au>\n\t<20160805072838.GF11268@linux.vnet.ibm.com>\n\t<87h9azin4g.fsf@concordia.ellerman.id.au>\n\t<20160805100609.GP2799@techsingularity.net>\n\t<87d1lhtb3s.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<87d1lhtb3s.fsf@concordia.ellerman.id.au>","User-Agent":"Mutt/1.5.23 (2014-03-12)","X-TM-AS-MML":"disable","X-Content-Scanned":"Fidelis XPS MAILER","x-cbid":"16081006-0044-0000-0000-000001CC3C14","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"16081006-0045-0000-0000-0000054B2B51","Message-Id":"<20160810064056.GB24800@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2016-08-10_05:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\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-1608100074","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 , linuxppc-dev@lists.ozlabs.org,\n\tMichal Hocko , linux-mm@kvack.org,\n\tMahesh Salgaonkar ,\n\tHari Bathini ,\n\tAndrew Morton ,\n\tMel Gorman ,\n\tVlastimil Babka ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1427722,"web_url":"http://patchwork.ozlabs.org/comment/1427722/","msgid":"<877fbpt8ju.fsf@concordia.ellerman.id.au>","date":"2016-08-10T06:57:57","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Srikar Dronamraju writes:\n\n>> \n>> > Conceptually it would be cleaner, if expensive, to calculate the real\n>> > memblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve\n>> > and nr_kernel_pages entirely.\n>> \n>> Why is it expensive? memblock tracks the totals for all memory and\n>> reserved memory AFAIK, so it should just be a case of subtracting one\n>> from the other?\n>\n> Are you suggesting that we use something like\n> memblock_phys_mem_size() but one which returns\n> memblock.reserved.total_size ? Maybe a new function like\n> memblock_reserved_mem_size()?\n\nYeah, something like that. I'm not sure if it actually needs a function,\nAFAIK you can just look at the structure directly.\n\n>> > Unfortuantely, aside from the calculation,\n>> > there is a potential cost due to a smaller hash table that affects everyone,\n>> > not just ppc64.\n>> \n>> Yeah OK. We could make it an arch hook, or controlled by a CONFIG.\n>\n> If its based on memblock.reserved.total_size, then should it be arch\n> specific?\n\nYes I think so. Otherwise you have to test it on every architecture :)\n\n>> > However, if the hash table is meant to be sized on the\n>> > number of available pages then it really should be based on that and not\n>> > just a made-up number.\n>> \n>> Yeah that seems to make sense.\n>> \n>> The one complication I think is that we may have memory that's marked\n>> reserved in memblock, but is later freed to the page allocator (eg.\n>> initrd).\n>\n> Yes, this is a possibility, for example lets say we want fadump to\n> continue to run instead of rebooting to a new kernel as it does today.\n\nBut that's a bad idea and no one should ever do it.\n\nFor starters all your caches will be undersized, and anything that is\nallocated per-node early in boot will not be allocated on the nodes\nwhich were reserved, so the system's performance will potentially differ\nfrom a normal boot in weird and unpredictable ways.\n\ncheers","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 3s8MSY6Lpjz9sf9\n\tfor ;\n\tWed, 10 Aug 2016 16:58:53 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s8MSY5RrjzDr1W\n\tfor ;\n\tWed, 10 Aug 2016 16:58:53 +1000 (AEST)","from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2])\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 3s8MRT4bqzzDqRR\n\tfor ;\n\tWed, 10 Aug 2016 16:57:57 +1000 (AEST)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3s8MRT3JRQz9sf9;\n\tWed, 10 Aug 2016 16:57:57 +1000 (AEST)"],"From":"Michael Ellerman ","To":"Srikar Dronamraju ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","In-Reply-To":"<20160810064056.GB24800@linux.vnet.ibm.com>","References":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<87mvkritii.fsf@concordia.ellerman.id.au>\n\t<20160805072838.GF11268@linux.vnet.ibm.com>\n\t<87h9azin4g.fsf@concordia.ellerman.id.au>\n\t<20160805100609.GP2799@techsingularity.net>\n\t<87d1lhtb3s.fsf@concordia.ellerman.id.au>\n\t<20160810064056.GB24800@linux.vnet.ibm.com>","User-Agent":"Notmuch/0.21 (https://notmuchmail.org)","Date":"Wed, 10 Aug 2016 16:57:57 +1000","Message-ID":"<877fbpt8ju.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","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 , linuxppc-dev@lists.ozlabs.org,\n\tMichal Hocko , linux-mm@kvack.org,\n\tMahesh Salgaonkar ,\n\tHari Bathini ,\n\tAndrew Morton ,\n\tMel Gorman ,\n\tVlastimil Babka ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1427761,"web_url":"http://patchwork.ozlabs.org/comment/1427761/","msgid":"<20160810075142.GC8119@techsingularity.net>","date":"2016-08-10T07:51:43","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","submitter":{"id":67639,"url":"http://patchwork.ozlabs.org/api/people/67639/","name":"Mel Gorman","email":"mgorman@techsingularity.net"},"content":"On Wed, Aug 10, 2016 at 04:02:47PM +1000, Michael Ellerman wrote:\n> > Conceptually it would be cleaner, if expensive, to calculate the real\n> > memblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve\n> > and nr_kernel_pages entirely.\n> \n> Why is it expensive? memblock tracks the totals for all memory and\n> reserved memory AFAIK, so it should just be a case of subtracting one\n> from the other?\n> \n\nI didn't actually check that it tracks the totals. If it does, then the cost\nwill be negligible in comparison to the total cost of initialising memory.\n\n> > Unfortuantely, aside from the calculation,\n> > there is a potential cost due to a smaller hash table that affects everyone,\n> > not just ppc64.\n> \n> Yeah OK. We could make it an arch hook, or controlled by a CONFIG.\n> \n> > However, if the hash table is meant to be sized on the\n> > number of available pages then it really should be based on that and not\n> > just a made-up number.\n> \n> Yeah that seems to make sense.\n> \n> The one complication I think is that we may have memory that's marked\n> reserved in memblock, but is later freed to the page allocator (eg.\n> initrd).\n> \n\nIt would be ideal if the amount of reserved memory that is freed later\nin the normal case was estimated. If it's a small percentage of memory\nthen the difference is unlikely to be detectable and avoids ppc64 being\nspecial.","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 3s8Nfn5shqz9stY\n\tfor ;\n\tWed, 10 Aug 2016 17:52:49 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s8Nfn4yqjzDqdb\n\tfor ;\n\tWed, 10 Aug 2016 17:52:49 +1000 (AEST)","from outbound-smtp03.blacknight.com (outbound-smtp03.blacknight.com\n\t[81.17.249.16])\n\t(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3s8Ndf0TJ0zDqQb\n\tfor ;\n\tWed, 10 Aug 2016 17:51:49 +1000 (AEST)","from mail.blacknight.com (pemlinmail04.blacknight.ie\n\t[81.17.254.17])\n\tby outbound-smtp03.blacknight.com (Postfix) with ESMTPS id 9AA3B991BA\n\tfor ;\n\tWed, 10 Aug 2016 07:51:44 +0000 (UTC)","(qmail 10633 invoked from network); 10 Aug 2016 07:51:44 -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); 10 Aug 2016 07:51:44 -0000"],"Date":"Wed, 10 Aug 2016 08:51:43 +0100","From":"Mel Gorman ","To":"Michael Ellerman ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","Message-ID":"<20160810075142.GC8119@techsingularity.net>","References":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<87mvkritii.fsf@concordia.ellerman.id.au>\n\t<20160805072838.GF11268@linux.vnet.ibm.com>\n\t<87h9azin4g.fsf@concordia.ellerman.id.au>\n\t<20160805100609.GP2799@techsingularity.net>\n\t<87d1lhtb3s.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-15","Content-Disposition":"inline","In-Reply-To":"<87d1lhtb3s.fsf@concordia.ellerman.id.au>","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":"Srikar Dronamraju ,\n\tDave Hansen ,\n\tMahesh Salgaonkar ,\n\tMichal Hocko , linux-mm@kvack.org,\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":1427800,"web_url":"http://patchwork.ozlabs.org/comment/1427800/","msgid":"<20160810092145.GA20502@linux.vnet.ibm.com>","date":"2016-08-10T09:21:45","subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","submitter":{"id":11795,"url":"http://patchwork.ozlabs.org/api/people/11795/","name":"Srikar Dronamraju","email":"srikar@linux.vnet.ibm.com"},"content":"* Michael Ellerman [2016-08-10 16:57:57]:\n\n> Srikar Dronamraju writes:\n> \n> >> \n> >> > Conceptually it would be cleaner, if expensive, to calculate the real\n> >> > memblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve\n> >> > and nr_kernel_pages entirely.\n> >> \n> >> Why is it expensive? memblock tracks the totals for all memory and\n> >> reserved memory AFAIK, so it should just be a case of subtracting one\n> >> from the other?\n> >\n> > Are you suggesting that we use something like\n> > memblock_phys_mem_size() but one which returns\n> > memblock.reserved.total_size ? Maybe a new function like\n> > memblock_reserved_mem_size()?\n> \n> Yeah, something like that. I'm not sure if it actually needs a function,\n> AFAIK you can just look at the structure directly.\n\nFor now memblock structure is only available in mm/memblock.c\nEvery other access to memblock from outside mm/memblock is through an\napi.\n\n> >\n> > Yes, this is a possibility, for example lets say we want fadump to\n> > continue to run instead of rebooting to a new kernel as it does today.\n> \n> But that's a bad idea and no one should ever do it.\n> \n> For starters all your caches will be undersized, and anything that is\n> allocated per-node early in boot will not be allocated on the nodes\n> which were reserved, so the system's performance will potentially differ\n> from a normal boot in weird and unpredictable ways.\n> \n\nOkay","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 3s8Qg00JL4z9t1L\n\tfor ;\n\tWed, 10 Aug 2016 19:23:08 +1000 (AEST)","from ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3s8Qfz6YyqzDr4J\n\tfor ;\n\tWed, 10 Aug 2016 19:23:07 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\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 3s8Qdt6TrNzDqRs\n\tfor ;\n\tWed, 10 Aug 2016 19:22:10 +1000 (AEST)","from pps.filterd (m0098413.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id\n\tu7A9JHlM057940\n\tfor ; Wed, 10 Aug 2016 05:22:08 -0400","from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com [202.81.31.142])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 24qm9uc2ug-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 10 Aug 2016 05:22:07 -0400","from localhost\n\tby e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ; \n\tWed, 10 Aug 2016 19:21:53 +1000","from d23dlp02.au.ibm.com (202.81.31.213)\n\tby e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 10 Aug 2016 19:21:50 +1000","from d23relay07.au.ibm.com (d23relay07.au.ibm.com [9.190.26.37])\n\tby d23dlp02.au.ibm.com (Postfix) with ESMTP id 2E1D12BB0055\n\tfor ;\n\tWed, 10 Aug 2016 19:21:50 +1000 (EST)","from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])\n\tby d23relay07.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tu7A9Lo7e30015634\n\tfor ; Wed, 10 Aug 2016 19:21:50 +1000","from d23av01.au.ibm.com (localhost [127.0.0.1])\n\tby d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tu7A9Lm6a020073\n\tfor ; Wed, 10 Aug 2016 19:21:49 +1000","from linux.vnet.ibm.com (srdronam.in.ibm.com [9.124.31.34])\n\tby d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id\n\tu7A9LjFK019835; Wed, 10 Aug 2016 19:21:46 +1000"],"X-IBM-Helo":"d23dlp02.au.ibm.com","X-IBM-MailFrom":"srikar@linux.vnet.ibm.com","X-IBM-RcptTo":"linuxppc-dev@lists.ozlabs.org","Date":"Wed, 10 Aug 2016 14:51:45 +0530","From":"Srikar Dronamraju ","To":"Michael Ellerman ","Subject":"Re: [PATCH] fadump: Register the memory reserved by fadump","References":"<1470318165-2521-1-git-send-email-srikar@linux.vnet.ibm.com>\n\t<87mvkritii.fsf@concordia.ellerman.id.au>\n\t<20160805072838.GF11268@linux.vnet.ibm.com>\n\t<87h9azin4g.fsf@concordia.ellerman.id.au>\n\t<20160805100609.GP2799@techsingularity.net>\n\t<87d1lhtb3s.fsf@concordia.ellerman.id.au>\n\t<20160810064056.GB24800@linux.vnet.ibm.com>\n\t<877fbpt8ju.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","In-Reply-To":"<877fbpt8ju.fsf@concordia.ellerman.id.au>","User-Agent":"Mutt/1.5.23 (2014-03-12)","X-TM-AS-MML":"disable","X-Content-Scanned":"Fidelis XPS MAILER","x-cbid":"16081009-0052-0000-0000-000001B8E8E6","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"16081009-0053-0000-0000-0000068BB85F","Message-Id":"<20160810092145.GA20502@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2016-08-10_07:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\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-1608100100","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 , linuxppc-dev@lists.ozlabs.org,\n\tMichal Hocko , linux-mm@kvack.org,\n\tMahesh Salgaonkar ,\n\tHari Bathini ,\n\tAndrew Morton ,\n\tMel Gorman ,\n\tVlastimil Babka ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}}]