From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753716AbdHKQEx (ORCPT ); Fri, 11 Aug 2017 12:04:53 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:47021 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753697AbdHKQEv (ORCPT ); Fri, 11 Aug 2017 12:04:51 -0400 Subject: Re: [v6 08/15] mm: zero struct pages during initialization To: Michal Hocko Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com, heiko.carstens@de.ibm.com, davem@davemloft.net, willy@infradead.org, ard.biesheuvel@linaro.org, will.deacon@arm.com, catalin.marinas@arm.com, sam@ravnborg.org References: <1502138329-123460-1-git-send-email-pasha.tatashin@oracle.com> <1502138329-123460-9-git-send-email-pasha.tatashin@oracle.com> <20170811125047.GJ30811@dhcp22.suse.cz> From: Pasha Tatashin Message-ID: Date: Fri, 11 Aug 2017 12:03:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170811125047.GJ30811@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: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I believe this deserves much more detailed explanation why this is safe. > What actually prevents any pfn walker from seeing an uninitialized > struct page? Please make your assumptions explicit in the commit log so > that we can check them independently. There is nothing prevents pfn walkers from walk over any struct pages deferred and non-deferred. However, during boot before deferred pages are initialized we have just a few places that do that, and all of those cases are fixed in this patchset. > Also this is done with some purpose which is the perfmance, right? You > have mentioned that in the cover letter but if somebody is going to read > through git logs this wouldn't be obvious from the specific commit. > So add that information here as well. Especially numbers will be > interesting. I will add more performance data to this patch comment.