[{"id":1778960,"web_url":"http://patchwork.ozlabs.org/comment/1778960/","msgid":"<20171003131817.omzbam3js67edp3s@dhcp22.suse.cz>","date":"2017-10-03T13:18:17","subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","submitter":{"id":66979,"url":"http://patchwork.ozlabs.org/api/people/66979/","name":"Michal Hocko","email":"mhocko@kernel.org"},"content":"On Wed 20-09-17 16:17:10, Pavel Tatashin wrote:\n> Some memory is reserved but unavailable: not present in memblock.memory\n> (because not backed by physical pages), but present in memblock.reserved.\n> Such memory has backing struct pages, but they are not initialized by going\n> through __init_single_page().\n\nCould you be more specific where is such a memory reserved?","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 ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y604M4qffz9t2M\n\tfor ;\n\tWed, 4 Oct 2017 00:19:31 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3y604M3yrCzDqp6\n\tfor ;\n\tWed, 4 Oct 2017 00:19:31 +1100 (AEDT)","from mx1.suse.de (mx2.suse.de [195.135.220.15])\n\t(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3y60325ZWXzDqNm\n\tfor ;\n\tWed, 4 Oct 2017 00:18:22 +1100 (AEDT)","from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])\n\tby mx1.suse.de (Postfix) with ESMTP id A3AF1AD6D;\n\tTue, 3 Oct 2017 13:18:18 +0000 (UTC)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=kernel.org\n\t(client-ip=195.135.220.15; helo=mx1.suse.de;\n\tenvelope-from=mhocko@kernel.org; receiver=)","X-Virus-Scanned":"by amavisd-new at test-mx.suse.de","Date":"Tue, 3 Oct 2017 15:18:17 +0200","From":"Michal Hocko ","To":"Pavel Tatashin ","Subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","Message-ID":"<20171003131817.omzbam3js67edp3s@dhcp22.suse.cz>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-9-pasha.tatashin@oracle.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170920201714.19817-9-pasha.tatashin@oracle.com>","User-Agent":"NeoMutt/20170609 (1.8.3)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","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":"mark.rutland@arm.com, linux-s390@vger.kernel.org,\n\tard.biesheuvel@linaro.org, \n\tmgorman@techsingularity.net, sam@ravnborg.org, borntraeger@de.ibm.com,\n\twill.deacon@arm.com, x86@kernel.org, heiko.carstens@de.ibm.com,\n\tlinux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,\n\tdaniel.m.jordan@oracle.com, linux-mm@kvack.org,\n\tsteven.sistare@oracle.com, willy@infradead.org, catalin.marinas@arm.com,\n\tsparclinux@vger.kernel.org, \n\tbob.picco@oracle.com, linuxppc-dev@lists.ozlabs.org,\n\tdavem@davemloft.net, linux-arm-kernel@lists.infradead.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1779084,"web_url":"http://patchwork.ozlabs.org/comment/1779084/","msgid":"<691dba28-718c-e9a9-d006-88505eb5cd7e@oracle.com>","date":"2017-10-03T15:29:16","subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":"On 10/03/2017 09:18 AM, Michal Hocko wrote:\n> On Wed 20-09-17 16:17:10, Pavel Tatashin wrote:\n>> Some memory is reserved but unavailable: not present in memblock.memory\n>> (because not backed by physical pages), but present in memblock.reserved.\n>> Such memory has backing struct pages, but they are not initialized by going\n>> through __init_single_page().\n> \n> Could you be more specific where is such a memory reserved?\n> \n\nI know of one example: trim_low_memory_range() unconditionally reserves \nfrom pfn 0, but e820__memblock_setup() might provide the exiting memory \nfrom pfn 1 (i.e. KVM).\n\nBut, there could be more based on this comment from linux/page-flags.h:\n\n 19 * PG_reserved is set for special pages, which can never be swapped \nout. Some\n 20 * of them might not even exist (eg empty_bad_page)...\n\nPasha","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 ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y631S25hkz9sRV\n\tfor ;\n\tWed, 4 Oct 2017 02:32:12 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3y631S19kKzDqpx\n\tfor ;\n\tWed, 4 Oct 2017 02:32:12 +1100 (AEDT)","from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81])\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 3y62zh1CtlzDqNm\n\tfor ;\n\tWed, 4 Oct 2017 02:30:39 +1100 (AEDT)","from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234])\n\tby userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2)\n\twith ESMTP id v93FTR9t006397\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Tue, 3 Oct 2017 15:29:28 GMT","from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])\n\tby aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v93FTQ1d020907\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Tue, 3 Oct 2017 15:29:27 GMT","from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])\n\tby userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v93FTPvc004296; \n\tTue, 3 Oct 2017 15:29:25 GMT","from [192.168.1.10] (/98.216.35.41)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Tue, 03 Oct 2017 08:29:25 -0700"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=oracle.com\n\t(client-ip=156.151.31.81; helo=userp1040.oracle.com;\n\tenvelope-from=pasha.tatashin@oracle.com; receiver=)","Subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","To":"Michal Hocko ","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-9-pasha.tatashin@oracle.com>\n\t<20171003131817.omzbam3js67edp3s@dhcp22.suse.cz>","From":"Pasha Tatashin ","Message-ID":"<691dba28-718c-e9a9-d006-88505eb5cd7e@oracle.com>","Date":"Tue, 3 Oct 2017 11:29:16 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20171003131817.omzbam3js67edp3s@dhcp22.suse.cz>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Source-IP":"aserv0022.oracle.com [141.146.126.234]","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","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":"mark.rutland@arm.com, linux-s390@vger.kernel.org,\n\tard.biesheuvel@linaro.org, \n\tmgorman@techsingularity.net, sam@ravnborg.org, borntraeger@de.ibm.com,\n\twill.deacon@arm.com, x86@kernel.org, heiko.carstens@de.ibm.com,\n\tlinux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,\n\tdaniel.m.jordan@oracle.com, linux-mm@kvack.org,\n\tsteven.sistare@oracle.com, willy@infradead.org, catalin.marinas@arm.com,\n\tsparclinux@vger.kernel.org, \n\tbob.picco@oracle.com, linuxppc-dev@lists.ozlabs.org,\n\tdavem@davemloft.net, linux-arm-kernel@lists.infradead.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1779539,"web_url":"http://patchwork.ozlabs.org/comment/1779539/","msgid":"<20171004085636.w2rnwf5xxhahzuy7@dhcp22.suse.cz>","date":"2017-10-04T08:56:36","subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","submitter":{"id":66979,"url":"http://patchwork.ozlabs.org/api/people/66979/","name":"Michal Hocko","email":"mhocko@kernel.org"},"content":"On Tue 03-10-17 11:29:16, Pasha Tatashin wrote:\n> On 10/03/2017 09:18 AM, Michal Hocko wrote:\n> > On Wed 20-09-17 16:17:10, Pavel Tatashin wrote:\n> > > Some memory is reserved but unavailable: not present in memblock.memory\n> > > (because not backed by physical pages), but present in memblock.reserved.\n> > > Such memory has backing struct pages, but they are not initialized by going\n> > > through __init_single_page().\n> > \n> > Could you be more specific where is such a memory reserved?\n> > \n> \n> I know of one example: trim_low_memory_range() unconditionally reserves from\n> pfn 0, but e820__memblock_setup() might provide the exiting memory from pfn\n> 1 (i.e. KVM).\n\nThen just initialize struct pages for that mapping rigth there where a\nspecial API is used.\n\n> But, there could be more based on this comment from linux/page-flags.h:\n> \n> 19 * PG_reserved is set for special pages, which can never be swapped out.\n> Some\n> 20 * of them might not even exist (eg empty_bad_page)...\n\nI have no idea wht empty_bad_page is but a quick grep shows that this is\nnever used. I might be wrong here but if somebody is reserving a memory\nin a special way then we should handle the initialization right there.\nE.g. create an API for special memblock reservations.","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 ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y6VCr1T5gz9sRV\n\tfor ;\n\tWed, 4 Oct 2017 19:57:44 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3y6VCr0d68zDqvJ\n\tfor ;\n\tWed, 4 Oct 2017 19:57:44 +1100 (AEDT)","from mx1.suse.de (mx2.suse.de [195.135.220.15])\n\t(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3y6VBc1TzdzDqms\n\tfor ;\n\tWed, 4 Oct 2017 19:56:40 +1100 (AEDT)","from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])\n\tby mx1.suse.de (Postfix) with ESMTP id 07AE7AAEF;\n\tWed, 4 Oct 2017 08:56:36 +0000 (UTC)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=kernel.org\n\t(client-ip=195.135.220.15; helo=mx1.suse.de;\n\tenvelope-from=mhocko@kernel.org; receiver=)","X-Virus-Scanned":"by amavisd-new at test-mx.suse.de","Date":"Wed, 4 Oct 2017 10:56:36 +0200","From":"Michal Hocko ","To":"Pasha Tatashin ","Subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","Message-ID":"<20171004085636.w2rnwf5xxhahzuy7@dhcp22.suse.cz>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-9-pasha.tatashin@oracle.com>\n\t<20171003131817.omzbam3js67edp3s@dhcp22.suse.cz>\n\t<691dba28-718c-e9a9-d006-88505eb5cd7e@oracle.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<691dba28-718c-e9a9-d006-88505eb5cd7e@oracle.com>","User-Agent":"NeoMutt/20170609 (1.8.3)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","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":"mark.rutland@arm.com, linux-s390@vger.kernel.org,\n\tard.biesheuvel@linaro.org, \n\tmgorman@techsingularity.net, sam@ravnborg.org, borntraeger@de.ibm.com,\n\twill.deacon@arm.com, x86@kernel.org, heiko.carstens@de.ibm.com,\n\tlinux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,\n\tdaniel.m.jordan@oracle.com, linux-mm@kvack.org,\n\tsteven.sistare@oracle.com, willy@infradead.org, catalin.marinas@arm.com,\n\tsparclinux@vger.kernel.org, \n\tbob.picco@oracle.com, linuxppc-dev@lists.ozlabs.org,\n\tdavem@davemloft.net, linux-arm-kernel@lists.infradead.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1779773,"web_url":"http://patchwork.ozlabs.org/comment/1779773/","msgid":"<9198a33d-cd40-dd70-4823-7f70c57ef9a2@oracle.com>","date":"2017-10-04T12:40:11","subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":">>> Could you be more specific where is such a memory reserved?\n>>>\n>>\n>> I know of one example: trim_low_memory_range() unconditionally reserves from\n>> pfn 0, but e820__memblock_setup() might provide the exiting memory from pfn\n>> 1 (i.e. KVM).\n> \n> Then just initialize struct pages for that mapping rigth there where a\n> special API is used.\n> \n>> But, there could be more based on this comment from linux/page-flags.h:\n>>\n>> 19 * PG_reserved is set for special pages, which can never be swapped out.\n>> Some\n>> 20 * of them might not even exist (eg empty_bad_page)...\n> \n> I have no idea wht empty_bad_page is but a quick grep shows that this is\n> never used. I might be wrong here but if somebody is reserving a memory\n> in a special way then we should handle the initialization right there.\n> E.g. create an API for special memblock reservations.\n> \n\nHi Michal,\n\nThe reservations happen before struct pages are allocated and mapped. \nSo, it is not always possible to do it at call sites.\n\nPreviously, I have solved this problem like this:\n\nhttps://patchwork.kernel.org/patch/9886163\n\nBut, I was not too happy with that approach, so I replaced it with the \ncurrent approach as it is more generic, and solves similar issues if \nthey happen in other places. Also, the comment in page-flags got me \nscared that there are probably other places perhaps on other \narchitectures that can have the similar issue.\n\nIn addition, I did not like my solution, I was simply shrinking the low \nreservation from:\n[0 - reserve_low) to [min_pfn - reserve_low), but if min_pfn > \nreserve_low can we skip low reservation entirely? I was not sure.\n\nThe current approach notifies us if there are such pages, and we can \nfix/remove them in the future without crashing kernel in the meantime.\n\nPasha","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 ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y6bCJ1RRxz9t2S\n\tfor ;\n\tWed, 4 Oct 2017 23:42:36 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3y6bCH737mzDqyK\n\tfor ;\n\tWed, 4 Oct 2017 23:42:35 +1100 (AEDT)","from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69])\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 3y6b9q5RS6zDqqQ\n\tfor ;\n\tWed, 4 Oct 2017 23:41:19 +1100 (AEDT)","from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233])\n\tby aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2)\n\twith ESMTP id v94CeGIH001666\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Wed, 4 Oct 2017 12:40:16 GMT","from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])\n\tby aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v94CeF12017474\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Wed, 4 Oct 2017 12:40:15 GMT","from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])\n\tby userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id\n\tv94CeDVh010487; Wed, 4 Oct 2017 12:40:14 GMT","from [192.168.1.10] (/98.216.35.41)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Wed, 04 Oct 2017 05:40:13 -0700"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=oracle.com\n\t(client-ip=141.146.126.69; helo=aserp1040.oracle.com;\n\tenvelope-from=pasha.tatashin@oracle.com; receiver=)","Subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","To":"Michal Hocko ","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-9-pasha.tatashin@oracle.com>\n\t<20171003131817.omzbam3js67edp3s@dhcp22.suse.cz>\n\t<691dba28-718c-e9a9-d006-88505eb5cd7e@oracle.com>\n\t<20171004085636.w2rnwf5xxhahzuy7@dhcp22.suse.cz>","From":"Pasha Tatashin ","Message-ID":"<9198a33d-cd40-dd70-4823-7f70c57ef9a2@oracle.com>","Date":"Wed, 4 Oct 2017 08:40:11 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20171004085636.w2rnwf5xxhahzuy7@dhcp22.suse.cz>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Source-IP":"aserv0021.oracle.com [141.146.126.233]","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","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":"mark.rutland@arm.com, linux-s390@vger.kernel.org,\n\tard.biesheuvel@linaro.org, \n\tmgorman@techsingularity.net, sam@ravnborg.org, borntraeger@de.ibm.com,\n\twill.deacon@arm.com, x86@kernel.org, heiko.carstens@de.ibm.com,\n\tlinux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,\n\tdaniel.m.jordan@oracle.com, linux-mm@kvack.org,\n\tsteven.sistare@oracle.com, willy@infradead.org, catalin.marinas@arm.com,\n\tsparclinux@vger.kernel.org, \n\tbob.picco@oracle.com, linuxppc-dev@lists.ozlabs.org,\n\tdavem@davemloft.net, linux-arm-kernel@lists.infradead.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1779788,"web_url":"http://patchwork.ozlabs.org/comment/1779788/","msgid":"<20171004125743.fm6mf2artbga76et@dhcp22.suse.cz>","date":"2017-10-04T12:57:43","subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","submitter":{"id":66979,"url":"http://patchwork.ozlabs.org/api/people/66979/","name":"Michal Hocko","email":"mhocko@kernel.org"},"content":"On Wed 04-10-17 08:40:11, Pasha Tatashin wrote:\n> > > > Could you be more specific where is such a memory reserved?\n> > > > \n> > > \n> > > I know of one example: trim_low_memory_range() unconditionally reserves from\n> > > pfn 0, but e820__memblock_setup() might provide the exiting memory from pfn\n> > > 1 (i.e. KVM).\n> > \n> > Then just initialize struct pages for that mapping rigth there where a\n> > special API is used.\n> > \n> > > But, there could be more based on this comment from linux/page-flags.h:\n> > > \n> > > 19 * PG_reserved is set for special pages, which can never be swapped out.\n> > > Some\n> > > 20 * of them might not even exist (eg empty_bad_page)...\n> > \n> > I have no idea wht empty_bad_page is but a quick grep shows that this is\n> > never used. I might be wrong here but if somebody is reserving a memory\n> > in a special way then we should handle the initialization right there.\n> > E.g. create an API for special memblock reservations.\n> > \n> \n> Hi Michal,\n> \n> The reservations happen before struct pages are allocated and mapped. So, it\n> is not always possible to do it at call sites.\n\nOK, I didn't realize that.\n \n> Previously, I have solved this problem like this:\n> \n> https://patchwork.kernel.org/patch/9886163\n> \n> But, I was not too happy with that approach, so I replaced it with the\n> current approach as it is more generic, and solves similar issues if they\n> happen in other places. Also, the comment in page-flags got me scared that\n> there are probably other places perhaps on other architectures that can have\n> the similar issue.\n\nI believe the comment is just stale. I have looked into empty_bad_page\nand it is just a relict. I plan to post a patch soon.\n\n> In addition, I did not like my solution, I was simply shrinking the low\n> reservation from:\n> [0 - reserve_low) to [min_pfn - reserve_low), but if min_pfn > reserve_low\n> can we skip low reservation entirely? I was not sure.\n> \n> The current approach notifies us if there are such pages, and we can\n> fix/remove them in the future without crashing kernel in the meantime.\n\nI am not really familiar with the trim_low_memory_range code path. I am\nnot even sure we have to care about it because nobody should be walking\npfns outside of any zone. I am worried that this patch adds a code which\nis not really used and it will just stay that way for ever because\nnobody will dare to change it as it is too obscure and not explained\nvery well. trim_low_memory_range is a good example of this. Why do we\neven reserve this range from the memory block allocator? The memory\nshouldn't be backed by any real memory and thus not in the allocator in\nthe first place, no?","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 ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y6bZC1b79z9t2c\n\tfor ;\n\tWed, 4 Oct 2017 23:58:59 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3y6bZB5JCyzDr34\n\tfor ;\n\tWed, 4 Oct 2017 23:58:58 +1100 (AEDT)","from mx1.suse.de (mx2.suse.de [195.135.220.15])\n\t(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3y6bY0248hzDqrP\n\tfor ;\n\tWed, 4 Oct 2017 23:57:55 +1100 (AEDT)","from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])\n\tby mx1.suse.de (Postfix) with ESMTP id 33BFBACFA;\n\tWed, 4 Oct 2017 12:57:50 +0000 (UTC)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=kernel.org\n\t(client-ip=195.135.220.15; helo=mx1.suse.de;\n\tenvelope-from=mhocko@kernel.org; receiver=)","X-Virus-Scanned":"by amavisd-new at test-mx.suse.de","Date":"Wed, 4 Oct 2017 14:57:43 +0200","From":"Michal Hocko ","To":"Pasha Tatashin ","Subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","Message-ID":"<20171004125743.fm6mf2artbga76et@dhcp22.suse.cz>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-9-pasha.tatashin@oracle.com>\n\t<20171003131817.omzbam3js67edp3s@dhcp22.suse.cz>\n\t<691dba28-718c-e9a9-d006-88505eb5cd7e@oracle.com>\n\t<20171004085636.w2rnwf5xxhahzuy7@dhcp22.suse.cz>\n\t<9198a33d-cd40-dd70-4823-7f70c57ef9a2@oracle.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<9198a33d-cd40-dd70-4823-7f70c57ef9a2@oracle.com>","User-Agent":"NeoMutt/20170609 (1.8.3)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","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":"mark.rutland@arm.com, linux-s390@vger.kernel.org,\n\tard.biesheuvel@linaro.org, \n\tmgorman@techsingularity.net, sam@ravnborg.org, borntraeger@de.ibm.com,\n\twill.deacon@arm.com, x86@kernel.org, heiko.carstens@de.ibm.com,\n\tlinux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,\n\tdaniel.m.jordan@oracle.com, linux-mm@kvack.org,\n\tsteven.sistare@oracle.com, willy@infradead.org, catalin.marinas@arm.com,\n\tsparclinux@vger.kernel.org, \n\tbob.picco@oracle.com, linuxppc-dev@lists.ozlabs.org,\n\tdavem@davemloft.net, linux-arm-kernel@lists.infradead.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1779819,"web_url":"http://patchwork.ozlabs.org/comment/1779819/","msgid":"","date":"2017-10-04T13:28:55","subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":"> I am not really familiar with the trim_low_memory_range code path. I am\n> not even sure we have to care about it because nobody should be walking\n> pfns outside of any zone.\n\nAccording to commit comments first 4K belongs to BIOS, so I think the \nmemory exists but BIOS may or may not report it to Linux. So, reserve it \nto make sure we never touch it.\n\n I am worried that this patch adds a code which\n> is not really used and it will just stay that way for ever because\n> nobody will dare to change it as it is too obscure and not explained\n> very well.\n\nI could explain mine code better. Perhaps add more comments, and explain \nwhen it can be removed?\n\n trim_low_memory_range is a good example of this. Why do we\n> even reserve this range from the memory block allocator? The memory\n> shouldn't be backed by any real memory and thus not in the allocator in\n> the first place, no?\n> \n\nSince it is not enforced in memblock that everything in reserved list \nmust be part of memory list, we can have it, and we need to make sure \nkernel does not panic. Otherwise, it is very hard to detect such bugs.","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 ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y6cHh1nMnz9t2l\n\tfor ;\n\tThu, 5 Oct 2017 00:31:28 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3y6cHh0rlVzDr4X\n\tfor ;\n\tThu, 5 Oct 2017 00:31:28 +1100 (AEDT)","from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81])\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 3y6cGB06zszDqsg\n\tfor ;\n\tThu, 5 Oct 2017 00:30:09 +1100 (AEDT)","from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74])\n\tby userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with\n\tESMTP id v94DT1AU020593\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Wed, 4 Oct 2017 13:29:01 GMT","from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])\n\tby userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv94DT0sH012100\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Wed, 4 Oct 2017 13:29:00 GMT","from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11])\n\tby aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv94DSwLu020790; Wed, 4 Oct 2017 13:28:58 GMT","from [192.168.1.10] (/98.216.35.41)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Wed, 04 Oct 2017 06:28:58 -0700"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=oracle.com\n\t(client-ip=156.151.31.81; helo=userp1040.oracle.com;\n\tenvelope-from=pasha.tatashin@oracle.com; receiver=)","Subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","To":"Michal Hocko ","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-9-pasha.tatashin@oracle.com>\n\t<20171003131817.omzbam3js67edp3s@dhcp22.suse.cz>\n\t<691dba28-718c-e9a9-d006-88505eb5cd7e@oracle.com>\n\t<20171004085636.w2rnwf5xxhahzuy7@dhcp22.suse.cz>\n\t<9198a33d-cd40-dd70-4823-7f70c57ef9a2@oracle.com>\n\t<20171004125743.fm6mf2artbga76et@dhcp22.suse.cz>","From":"Pasha Tatashin ","Message-ID":"","Date":"Wed, 4 Oct 2017 09:28:55 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20171004125743.fm6mf2artbga76et@dhcp22.suse.cz>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Source-IP":"userv0022.oracle.com [156.151.31.74]","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","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":"mark.rutland@arm.com, linux-s390@vger.kernel.org,\n\tard.biesheuvel@linaro.org, \n\tmgorman@techsingularity.net, sam@ravnborg.org, borntraeger@de.ibm.com,\n\twill.deacon@arm.com, x86@kernel.org, heiko.carstens@de.ibm.com,\n\tlinux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,\n\tdaniel.m.jordan@oracle.com, linux-mm@kvack.org,\n\tsteven.sistare@oracle.com, willy@infradead.org, catalin.marinas@arm.com,\n\tsparclinux@vger.kernel.org, \n\tbob.picco@oracle.com, linuxppc-dev@lists.ozlabs.org,\n\tdavem@davemloft.net, linux-arm-kernel@lists.infradead.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1779852,"web_url":"http://patchwork.ozlabs.org/comment/1779852/","msgid":"<20171004140410.2w2zf2gbutdxunir@dhcp22.suse.cz>","date":"2017-10-04T14:04:10","subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","submitter":{"id":66979,"url":"http://patchwork.ozlabs.org/api/people/66979/","name":"Michal Hocko","email":"mhocko@kernel.org"},"content":"On Wed 04-10-17 09:28:55, Pasha Tatashin wrote:\n> \n> > I am not really familiar with the trim_low_memory_range code path. I am\n> > not even sure we have to care about it because nobody should be walking\n> > pfns outside of any zone.\n> \n> According to commit comments first 4K belongs to BIOS, so I think the memory\n> exists but BIOS may or may not report it to Linux. So, reserve it to make\n> sure we never touch it.\n\nYes and that memory should be outside of any zones, no?\n\n> > I am worried that this patch adds a code which\n> > is not really used and it will just stay that way for ever because\n> > nobody will dare to change it as it is too obscure and not explained\n> > very well.\n> \n> I could explain mine code better. Perhaps add more comments, and explain\n> when it can be removed?\n\nMore explanation would be definitely helpful\n\n> > trim_low_memory_range is a good example of this. Why do we\n> > even reserve this range from the memory block allocator? The memory\n> > shouldn't be backed by any real memory and thus not in the allocator in\n> > the first place, no?\n> > \n> \n> Since it is not enforced in memblock that everything in reserved list must\n> be part of memory list, we can have it, and we need to make sure kernel does\n> not panic. Otherwise, it is very hard to detect such bugs.\n\nSo, should we report such a memblock reservation API (ab)use to the log?\nAre you actually sure that trim_low_memory_range is doing a sane and\nreally needed thing? In other words do we have a zone which contains\nthis no-memory backed pfns?","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 ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y6d311T9Mz9t2l\n\tfor ;\n\tThu, 5 Oct 2017 01:05:33 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3y6d310NLFzDr0y\n\tfor ;\n\tThu, 5 Oct 2017 01:05:33 +1100 (AEDT)","from mx1.suse.de (mx2.suse.de [195.135.220.15])\n\t(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3y6d1X17SszDqsn\n\tfor ;\n\tThu, 5 Oct 2017 01:04:15 +1100 (AEDT)","from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])\n\tby mx1.suse.de (Postfix) with ESMTP id 2DAB1ADED;\n\tWed, 4 Oct 2017 14:04:12 +0000 (UTC)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=kernel.org\n\t(client-ip=195.135.220.15; helo=mx1.suse.de;\n\tenvelope-from=mhocko@kernel.org; receiver=)","X-Virus-Scanned":"by amavisd-new at test-mx.suse.de","Date":"Wed, 4 Oct 2017 16:04:10 +0200","From":"Michal Hocko ","To":"Pasha Tatashin ","Subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","Message-ID":"<20171004140410.2w2zf2gbutdxunir@dhcp22.suse.cz>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-9-pasha.tatashin@oracle.com>\n\t<20171003131817.omzbam3js67edp3s@dhcp22.suse.cz>\n\t<691dba28-718c-e9a9-d006-88505eb5cd7e@oracle.com>\n\t<20171004085636.w2rnwf5xxhahzuy7@dhcp22.suse.cz>\n\t<9198a33d-cd40-dd70-4823-7f70c57ef9a2@oracle.com>\n\t<20171004125743.fm6mf2artbga76et@dhcp22.suse.cz>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170609 (1.8.3)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","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":"mark.rutland@arm.com, linux-s390@vger.kernel.org,\n\tard.biesheuvel@linaro.org, \n\tmgorman@techsingularity.net, sam@ravnborg.org, borntraeger@de.ibm.com,\n\twill.deacon@arm.com, x86@kernel.org, heiko.carstens@de.ibm.com,\n\tlinux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,\n\tdaniel.m.jordan@oracle.com, linux-mm@kvack.org,\n\tsteven.sistare@oracle.com, willy@infradead.org, catalin.marinas@arm.com,\n\tsparclinux@vger.kernel.org, \n\tbob.picco@oracle.com, linuxppc-dev@lists.ozlabs.org,\n\tdavem@davemloft.net, linux-arm-kernel@lists.infradead.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1779925,"web_url":"http://patchwork.ozlabs.org/comment/1779925/","msgid":"","date":"2017-10-04T15:08:59","subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":"On 10/04/2017 10:04 AM, Michal Hocko wrote:\n> On Wed 04-10-17 09:28:55, Pasha Tatashin wrote:\n>>\n>>> I am not really familiar with the trim_low_memory_range code path. I am\n>>> not even sure we have to care about it because nobody should be walking\n>>> pfns outside of any zone.\n>>\n>> According to commit comments first 4K belongs to BIOS, so I think the memory\n>> exists but BIOS may or may not report it to Linux. So, reserve it to make\n>> sure we never touch it.\n> \n> Yes and that memory should be outside of any zones, no?\n\nI am not totally sure, I think some x86 expert could help us here. But, \nin either case this issue can be fixed separately from the rest of the \nseries.\n\n> \n>>> I am worried that this patch adds a code which\n>>> is not really used and it will just stay that way for ever because\n>>> nobody will dare to change it as it is too obscure and not explained\n>>> very well.\n>>\n>> I could explain mine code better. Perhaps add more comments, and explain\n>> when it can be removed?\n> \n> More explanation would be definitely helpful\n> \n>>> trim_low_memory_range is a good example of this. Why do we\n>>> even reserve this range from the memory block allocator? The memory\n>>> shouldn't be backed by any real memory and thus not in the allocator in\n>>> the first place, no?\n>>>\n>>\n>> Since it is not enforced in memblock that everything in reserved list must\n>> be part of memory list, we can have it, and we need to make sure kernel does\n>> not panic. Otherwise, it is very hard to detect such bugs.\n> \n> So, should we report such a memblock reservation API (ab)use to the log?\n> Are you actually sure that trim_low_memory_range is doing a sane and\n> really needed thing? In other words do we have a zone which contains\n> this no-memory backed pfns?\n> \n\nAnd, this patch reports it already:\n\n+\tpr_info(\"Reserved but unavailable: %lld pages\", pgcnt);\n\nI could add a comment above this print call, explain that such memory is \nprobably bogus and must be studied/fixed. Also, add that this code can \nbe removed once memblock is changed to allow reserve only memory that is \nbacked by physical memory i.e. in \"memory\" list.\n\nPasha","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 ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y6fWL0Ry0z9t1G\n\tfor ;\n\tThu, 5 Oct 2017 02:11:42 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3y6fWK6PZCzDr3W\n\tfor ;\n\tThu, 5 Oct 2017 02:11:41 +1100 (AEDT)","from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69])\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 3y6fTt3LvrzDqsg\n\tfor ;\n\tThu, 5 Oct 2017 02:10:25 +1100 (AEDT)","from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234])\n\tby aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2)\n\twith ESMTP id v94F951W031914\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Wed, 4 Oct 2017 15:09:06 GMT","from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])\n\tby aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv94F94Cv017140\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Wed, 4 Oct 2017 15:09:04 GMT","from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15])\n\tby aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv94F91Xp031016; Wed, 4 Oct 2017 15:09:02 GMT","from [10.154.139.198] (/10.154.139.198)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Wed, 04 Oct 2017 08:09:01 -0700"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=oracle.com\n\t(client-ip=141.146.126.69; helo=aserp1040.oracle.com;\n\tenvelope-from=pasha.tatashin@oracle.com; receiver=)","Subject":"Re: [PATCH v9 08/12] mm: zero reserved and unavailable struct pages","To":"Michal Hocko ","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-9-pasha.tatashin@oracle.com>\n\t<20171003131817.omzbam3js67edp3s@dhcp22.suse.cz>\n\t<691dba28-718c-e9a9-d006-88505eb5cd7e@oracle.com>\n\t<20171004085636.w2rnwf5xxhahzuy7@dhcp22.suse.cz>\n\t<9198a33d-cd40-dd70-4823-7f70c57ef9a2@oracle.com>\n\t<20171004125743.fm6mf2artbga76et@dhcp22.suse.cz>\n\t\n\t<20171004140410.2w2zf2gbutdxunir@dhcp22.suse.cz>","From":"Pasha Tatashin ","Message-ID":"","Date":"Wed, 4 Oct 2017 11:08:59 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20171004140410.2w2zf2gbutdxunir@dhcp22.suse.cz>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Source-IP":"aserv0022.oracle.com [141.146.126.234]","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","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":"mark.rutland@arm.com, linux-s390@vger.kernel.org,\n\tard.biesheuvel@linaro.org, \n\tmgorman@techsingularity.net, sam@ravnborg.org, borntraeger@de.ibm.com,\n\twill.deacon@arm.com, x86@kernel.org, heiko.carstens@de.ibm.com,\n\tlinux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,\n\tdaniel.m.jordan@oracle.com, linux-mm@kvack.org,\n\tsteven.sistare@oracle.com, willy@infradead.org, catalin.marinas@arm.com,\n\tsparclinux@vger.kernel.org, \n\tbob.picco@oracle.com, linuxppc-dev@lists.ozlabs.org,\n\tdavem@davemloft.net, linux-arm-kernel@lists.infradead.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}}]