[{"id":1778962,"web_url":"http://patchwork.ozlabs.org/comment/1778962/","msgid":"<20171003131952.aqq377pjug5me6go@dhcp22.suse.cz>","list_archive_url":null,"date":"2017-10-03T13:19:52","subject":"Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in\n\tvmemmap","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:14, Pavel Tatashin wrote:\n> vmemmap_alloc_block() will no longer zero the block, so zero memory\n> at its call sites for everything except struct pages. Struct page memory\n> is zero'd by struct page initialization.\n> \n> Replace allocators in sprase-vmemmap to use the non-zeroing version. So,\n> we will get the performance improvement by zeroing the memory in parallel\n> when struct pages are zeroed.\n\nIs it possible to merge this patch with http://lkml.kernel.org/r/20170920201714.19817-7-pasha.tatashin@oracle.com\n\n> Signed-off-by: Pavel Tatashin \n> Reviewed-by: Steven Sistare \n> Reviewed-by: Daniel Jordan \n> Reviewed-by: Bob Picco \n> ---\n> include/linux/mm.h | 11 +++++++++++\n> mm/sparse-vmemmap.c | 15 +++++++--------\n> mm/sparse.c | 6 +++---\n> 3 files changed, 21 insertions(+), 11 deletions(-)\n> \n> diff --git a/include/linux/mm.h b/include/linux/mm.h\n> index a7bba4ce79ba..25848764570f 100644\n> --- a/include/linux/mm.h\n> +++ b/include/linux/mm.h\n> @@ -2501,6 +2501,17 @@ static inline void *vmemmap_alloc_block_buf(unsigned long size, int node)\n> \treturn __vmemmap_alloc_block_buf(size, node, NULL);\n> }\n> \n> +static inline void *vmemmap_alloc_block_zero(unsigned long size, int node)\n> +{\n> +\tvoid *p = vmemmap_alloc_block(size, node);\n> +\n> +\tif (!p)\n> +\t\treturn NULL;\n> +\tmemset(p, 0, size);\n> +\n> +\treturn p;\n> +}\n> +\n> void vmemmap_verify(pte_t *, int, unsigned long, unsigned long);\n> int vmemmap_populate_basepages(unsigned long start, unsigned long end,\n> \t\t\t int node);\n> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c\n> index d1a39b8051e0..c2f5654e7c9d 100644\n> --- a/mm/sparse-vmemmap.c\n> +++ b/mm/sparse-vmemmap.c\n> @@ -41,7 +41,7 @@ static void * __ref __earlyonly_bootmem_alloc(int node,\n> \t\t\t\tunsigned long align,\n> \t\t\t\tunsigned long goal)\n> {\n> -\treturn memblock_virt_alloc_try_nid(size, align, goal,\n> +\treturn memblock_virt_alloc_try_nid_raw(size, align, goal,\n> \t\t\t\t\t BOOTMEM_ALLOC_ACCESSIBLE, node);\n> }\n> \n> @@ -54,9 +54,8 @@ void * __meminit vmemmap_alloc_block(unsigned long size, int node)\n> \tif (slab_is_available()) {\n> \t\tstruct page *page;\n> \n> -\t\tpage = alloc_pages_node(node,\n> -\t\t\tGFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL,\n> -\t\t\tget_order(size));\n> +\t\tpage = alloc_pages_node(node, GFP_KERNEL | __GFP_RETRY_MAYFAIL,\n> +\t\t\t\t\tget_order(size));\n> \t\tif (page)\n> \t\t\treturn page_address(page);\n> \t\treturn NULL;\n> @@ -183,7 +182,7 @@ pmd_t * __meminit vmemmap_pmd_populate(pud_t *pud, unsigned long addr, int node)\n> {\n> \tpmd_t *pmd = pmd_offset(pud, addr);\n> \tif (pmd_none(*pmd)) {\n> -\t\tvoid *p = vmemmap_alloc_block(PAGE_SIZE, node);\n> +\t\tvoid *p = vmemmap_alloc_block_zero(PAGE_SIZE, node);\n> \t\tif (!p)\n> \t\t\treturn NULL;\n> \t\tpmd_populate_kernel(&init_mm, pmd, p);\n> @@ -195,7 +194,7 @@ pud_t * __meminit vmemmap_pud_populate(p4d_t *p4d, unsigned long addr, int node)\n> {\n> \tpud_t *pud = pud_offset(p4d, addr);\n> \tif (pud_none(*pud)) {\n> -\t\tvoid *p = vmemmap_alloc_block(PAGE_SIZE, node);\n> +\t\tvoid *p = vmemmap_alloc_block_zero(PAGE_SIZE, node);\n> \t\tif (!p)\n> \t\t\treturn NULL;\n> \t\tpud_populate(&init_mm, pud, p);\n> @@ -207,7 +206,7 @@ p4d_t * __meminit vmemmap_p4d_populate(pgd_t *pgd, unsigned long addr, int node)\n> {\n> \tp4d_t *p4d = p4d_offset(pgd, addr);\n> \tif (p4d_none(*p4d)) {\n> -\t\tvoid *p = vmemmap_alloc_block(PAGE_SIZE, node);\n> +\t\tvoid *p = vmemmap_alloc_block_zero(PAGE_SIZE, node);\n> \t\tif (!p)\n> \t\t\treturn NULL;\n> \t\tp4d_populate(&init_mm, p4d, p);\n> @@ -219,7 +218,7 @@ pgd_t * __meminit vmemmap_pgd_populate(unsigned long addr, int node)\n> {\n> \tpgd_t *pgd = pgd_offset_k(addr);\n> \tif (pgd_none(*pgd)) {\n> -\t\tvoid *p = vmemmap_alloc_block(PAGE_SIZE, node);\n> +\t\tvoid *p = vmemmap_alloc_block_zero(PAGE_SIZE, node);\n> \t\tif (!p)\n> \t\t\treturn NULL;\n> \t\tpgd_populate(&init_mm, pgd, p);\n> diff --git a/mm/sparse.c b/mm/sparse.c\n> index 83b3bf6461af..d22f51bb7c79 100644\n> --- a/mm/sparse.c\n> +++ b/mm/sparse.c\n> @@ -437,9 +437,9 @@ void __init sparse_mem_maps_populate_node(struct page **map_map,\n> \t}\n> \n> \tsize = PAGE_ALIGN(size);\n> -\tmap = memblock_virt_alloc_try_nid(size * map_count,\n> -\t\t\t\t\t PAGE_SIZE, __pa(MAX_DMA_ADDRESS),\n> -\t\t\t\t\t BOOTMEM_ALLOC_ACCESSIBLE, nodeid);\n> +\tmap = memblock_virt_alloc_try_nid_raw(size * map_count,\n> +\t\t\t\t\t PAGE_SIZE, __pa(MAX_DMA_ADDRESS),\n> +\t\t\t\t\t BOOTMEM_ALLOC_ACCESSIBLE, nodeid);\n> \tif (map) {\n> \t\tfor (pnum = pnum_begin; pnum < pnum_end; pnum++) {\n> \t\t\tif (!present_section_nr(pnum))\n> -- \n> 2.14.1","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=sparclinux-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y605737f0z9t2Z\n\tfor ;\n\tWed, 4 Oct 2017 00:20:11 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752180AbdJCNT5 (ORCPT );\n\tTue, 3 Oct 2017 09:19:57 -0400","from mx2.suse.de ([195.135.220.15]:47907 \"EHLO mx1.suse.de\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S1751252AbdJCNTy (ORCPT );\n\tTue, 3 Oct 2017 09:19:54 -0400","from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])\n\tby mx1.suse.de (Postfix) with ESMTP id B35EFAD6D;\n\tTue, 3 Oct 2017 13:19:52 +0000 (UTC)"],"X-Virus-Scanned":"by amavisd-new at test-mx.suse.de","Date":"Tue, 3 Oct 2017 15:19:52 +0200","From":"Michal Hocko ","To":"Pavel Tatashin ","Cc":"linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,\n\tlinux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tx86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com,\n\theiko.carstens@de.ibm.com, davem@davemloft.net,\n\twilly@infradead.org, ard.biesheuvel@linaro.org,\n\tmark.rutland@arm.com, will.deacon@arm.com, catalin.marinas@arm.com,\n\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tsteven.sistare@oracle.com, daniel.m.jordan@oracle.com,\n\tbob.picco@oracle.com","Subject":"Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in\n\tvmemmap","Message-ID":"<20171003131952.aqq377pjug5me6go@dhcp22.suse.cz>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-13-pasha.tatashin@oracle.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170920201714.19817-13-pasha.tatashin@oracle.com>","User-Agent":"NeoMutt/20170609 (1.8.3)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1779087,"web_url":"http://patchwork.ozlabs.org/comment/1779087/","msgid":"","list_archive_url":null,"date":"2017-10-03T15:34:25","subject":"Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in\n\tvmemmap","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:19 AM, Michal Hocko wrote:\n> On Wed 20-09-17 16:17:14, Pavel Tatashin wrote:\n>> vmemmap_alloc_block() will no longer zero the block, so zero memory\n>> at its call sites for everything except struct pages. Struct page memory\n>> is zero'd by struct page initialization.\n>>\n>> Replace allocators in sprase-vmemmap to use the non-zeroing version. So,\n>> we will get the performance improvement by zeroing the memory in parallel\n>> when struct pages are zeroed.\n> \n> Is it possible to merge this patch with http://lkml.kernel.org/r/20170920201714.19817-7-pasha.tatashin@oracle.com\n\nYes, I will do that. It would also require re-arranging\n[PATCH v9 07/12] sparc64: optimized struct page zeroing\noptimization to come after this patch.\n\nPasha\n--\nTo unsubscribe from this list: send the line \"unsubscribe sparclinux\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=sparclinux-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y635R6H1rz9sMN\n\tfor ;\n\tWed, 4 Oct 2017 02:35:39 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751953AbdJCPfi (ORCPT );\n\tTue, 3 Oct 2017 11:35:38 -0400","from userp1040.oracle.com ([156.151.31.81]:17445 \"EHLO\n\tuserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751969AbdJCPfh (ORCPT\n\t); Tue, 3 Oct 2017 11:35:37 -0400","from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233])\n\tby userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2)\n\twith ESMTP id v93FYTnZ015606\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Tue, 3 Oct 2017 15:34:29 GMT","from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])\n\tby aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv93FYSQE001013\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Tue, 3 Oct 2017 15:34:28 GMT","from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])\n\tby aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv93FYSqb015610; Tue, 3 Oct 2017 15:34:28 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:34:27 -0700"],"Subject":"Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in\n\tvmemmap","To":"Michal Hocko ","Cc":"linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,\n\tlinux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tx86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com,\n\theiko.carstens@de.ibm.com, davem@davemloft.net,\n\twilly@infradead.org, ard.biesheuvel@linaro.org,\n\tmark.rutland@arm.com, will.deacon@arm.com, catalin.marinas@arm.com,\n\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tsteven.sistare@oracle.com, daniel.m.jordan@oracle.com,\n\tbob.picco@oracle.com","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-13-pasha.tatashin@oracle.com>\n\t<20171003131952.aqq377pjug5me6go@dhcp22.suse.cz>","From":"Pasha Tatashin ","Message-ID":"","Date":"Tue, 3 Oct 2017 11:34:25 -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":"<20171003131952.aqq377pjug5me6go@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]","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1779241,"web_url":"http://patchwork.ozlabs.org/comment/1779241/","msgid":"","list_archive_url":null,"date":"2017-10-03T20:26:51","subject":"Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in\n\tvmemmap","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":"Hi Michal,\n\nI decided not to merge these two patches, because in addition to sparc \noptimization move, we have this dependancies:\n\nmm: zero reserved and unavailable struct pages\n\nmust be before\n\nmm: stop zeroing memory during allocation in vmemmap.\n\nOtherwise, we can end-up with struct pages that are not zeroed properly.\n\nHowever, the first patch depends on\nmm: zero struct pages during initialization\n\nAs it uses mm_zero_struct_page().\n\nPasha\n\n\nOn 10/03/2017 11:34 AM, Pasha Tatashin wrote:\n> On 10/03/2017 09:19 AM, Michal Hocko wrote:\n>> On Wed 20-09-17 16:17:14, Pavel Tatashin wrote:\n>>> vmemmap_alloc_block() will no longer zero the block, so zero memory\n>>> at its call sites for everything except struct pages.  Struct page \n>>> memory\n>>> is zero'd by struct page initialization.\n>>>\n>>> Replace allocators in sprase-vmemmap to use the non-zeroing version. So,\n>>> we will get the performance improvement by zeroing the memory in \n>>> parallel\n>>> when struct pages are zeroed.\n>>\n>> Is it possible to merge this patch with \n>> http://lkml.kernel.org/r/20170920201714.19817-7-pasha.tatashin@oracle.com\n> \n> Yes, I will do that. It would also require re-arranging\n> [PATCH v9 07/12] sparc64: optimized struct page zeroing\n> optimization to come after this patch.\n> \n> Pasha\n--\nTo unsubscribe from this list: send the line \"unsubscribe sparclinux\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=sparclinux-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y69b94ZJGz9t5Y\n\tfor ;\n\tWed, 4 Oct 2017 07:28:21 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751953AbdJCU2U (ORCPT );\n\tTue, 3 Oct 2017 16:28:20 -0400","from userp1040.oracle.com ([156.151.31.81]:33887 \"EHLO\n\tuserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751820AbdJCU2T (ORCPT\n\t); Tue, 3 Oct 2017 16:28:19 -0400","from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71])\n\tby userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with\n\tESMTP id v93KQxxf016657\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Tue, 3 Oct 2017 20:27:00 GMT","from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])\n\tby userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv93KQvRd029605\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Tue, 3 Oct 2017 20:26:57 GMT","from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])\n\tby aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id\n\tv93KQtEY030670; Tue, 3 Oct 2017 20:26:55 GMT","from [10.154.106.162] (/10.154.106.162)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Tue, 03 Oct 2017 13:26:54 -0700"],"Subject":"Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in\n\tvmemmap","From":"Pasha Tatashin ","To":"Michal Hocko ","Cc":"linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,\n\tlinux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tx86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com,\n\theiko.carstens@de.ibm.com, davem@davemloft.net,\n\twilly@infradead.org, ard.biesheuvel@linaro.org,\n\tmark.rutland@arm.com, will.deacon@arm.com, catalin.marinas@arm.com,\n\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tsteven.sistare@oracle.com, daniel.m.jordan@oracle.com,\n\tbob.picco@oracle.com","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-13-pasha.tatashin@oracle.com>\n\t<20171003131952.aqq377pjug5me6go@dhcp22.suse.cz>\n\t","Message-ID":"","Date":"Tue, 3 Oct 2017 16:26:51 -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":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-Source-IP":"userv0021.oracle.com [156.151.31.71]","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1779528,"web_url":"http://patchwork.ozlabs.org/comment/1779528/","msgid":"<20171004084526.57uzy3t4ualwxdyt@dhcp22.suse.cz>","list_archive_url":null,"date":"2017-10-04T08:45:26","subject":"Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in\n\tvmemmap","submitter":{"id":66979,"url":"http://patchwork.ozlabs.org/api/people/66979/","name":"Michal Hocko","email":"mhocko@kernel.org"},"content":"On Tue 03-10-17 16:26:51, Pasha Tatashin wrote:\n> Hi Michal,\n> \n> I decided not to merge these two patches, because in addition to sparc\n> optimization move, we have this dependancies:\n\noptimizations can and should go on top of the core patch.\n\n> mm: zero reserved and unavailable struct pages\n> \n> must be before\n> \n> mm: stop zeroing memory during allocation in vmemmap.\n> \n> Otherwise, we can end-up with struct pages that are not zeroed properly.\n\nRight and you can deal with it easily. Just introduce the\nmm_zero_struct_page earlier along with its user in \"stop zeroing ...\"\n\nI think that moving the zeroying in one go is more reasonable than\nadding it to __init_single_page with misleading numbers and later\ndropping the zeroying from the memmap path.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=sparclinux-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y6Ty62Cnbz9sPt\n\tfor ;\n\tWed, 4 Oct 2017 19:45:50 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751946AbdJDIpb (ORCPT );\n\tWed, 4 Oct 2017 04:45:31 -0400","from mx2.suse.de ([195.135.220.15]:60218 \"EHLO mx1.suse.de\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S1751736AbdJDIp3 (ORCPT );\n\tWed, 4 Oct 2017 04:45:29 -0400","from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])\n\tby mx1.suse.de (Postfix) with ESMTP id AB9C1AC05;\n\tWed, 4 Oct 2017 08:45:27 +0000 (UTC)"],"X-Virus-Scanned":"by amavisd-new at test-mx.suse.de","Date":"Wed, 4 Oct 2017 10:45:26 +0200","From":"Michal Hocko ","To":"Pasha Tatashin ","Cc":"linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,\n\tlinux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tx86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com,\n\theiko.carstens@de.ibm.com, davem@davemloft.net,\n\twilly@infradead.org, ard.biesheuvel@linaro.org,\n\tmark.rutland@arm.com, will.deacon@arm.com, catalin.marinas@arm.com,\n\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tsteven.sistare@oracle.com, daniel.m.jordan@oracle.com,\n\tbob.picco@oracle.com","Subject":"Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in\n\tvmemmap","Message-ID":"<20171004084526.57uzy3t4ualwxdyt@dhcp22.suse.cz>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-13-pasha.tatashin@oracle.com>\n\t<20171003131952.aqq377pjug5me6go@dhcp22.suse.cz>\n\t\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)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}}]