From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752736AbdEOXRZ (ORCPT ); Mon, 15 May 2017 19:17:25 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:46126 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751631AbdEOXRX (ORCPT ); Mon, 15 May 2017 19:17:23 -0400 Date: Tue, 16 May 2017 01:17:16 +0200 From: Heiko Carstens To: Pasha Tatashin Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, borntraeger@de.ibm.com, davem@davemloft.net Subject: Re: [v3 9/9] s390: teach platforms not to zero struct pages memory References: <1494003796-748672-1-git-send-email-pasha.tatashin@oracle.com> <1494003796-748672-10-git-send-email-pasha.tatashin@oracle.com> <20170508113624.GA4876@osiris> <0669a945-4540-096e-799a-2d2b3c18abaa@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0669a945-4540-096e-799a-2d2b3c18abaa@oracle.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 17051523-0008-0000-0000-00000448998C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051523-0009-0000-0000-00001DAFC983 Message-Id: <20170515231716.GA3314@osiris> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-15_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705150220 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Pasha, > Thank you for looking at this patch. I am worried to make the proposed > change, because, as I understand in this case we allocate memory not for > "struct page"s but for table that hold them. So, we will change the behavior > from the current one, where this table is allocated zeroed, but now it won't > be zeroed. The page table, if needed, is allocated and populated a couple of lines above. See the vmem_pte_alloc() call. So my request to include the hunk below is still valid ;) > >If you add the hunk below then this is > > > >Acked-by: Heiko Carstens > > > >diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c > >index ffe9ba1aec8b..bf88a8b9c24d 100644 > >--- a/arch/s390/mm/vmem.c > >+++ b/arch/s390/mm/vmem.c > >@@ -272,7 +272,7 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node) > > if (pte_none(*pt_dir)) { > > void *new_page; > >- new_page = vmemmap_alloc_block(PAGE_SIZE, node, true); > >+ new_page = vmemmap_alloc_block(PAGE_SIZE, node, VMEMMAP_ZERO); > > if (!new_page) > > goto out; > > pte_val(*pt_dir) = __pa(new_page) | pgt_prot; > > >