Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752295AbdGaO2A (ORCPT ); Mon, 31 Jul 2017 10:28:00 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:46700 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750987AbdGaO17 (ORCPT ); Mon, 31 Jul 2017 10:27:59 -0400 Date: Mon, 31 Jul 2017 16:27:46 +0200 From: Gerald Schaefer To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Vlastimil Babka , Andrea Arcangeli , Jerome Glisse , Reza Arbab , Yasuaki Ishimatsu , qiuxishi@huawei.com, Kani Toshimitsu , slaoub@gmail.com, Joonsoo Kim , Andi Kleen , Daniel Kiper , Igor Mammedov , Vitaly Kuznetsov , LKML , Benjamin Herrenschmidt , Catalin Marinas , Fenghua Yu , Heiko Carstens , "H. Peter Anvin" , Ingo Molnar , Martin Schwidefsky , Michael Ellerman , Paul Mackerras , Thomas Gleixner , Tony Luck , Will Deacon , gerald.schaefer@de.ibm.com Subject: Re: [RFC PATCH 2/5] mm, arch: unify vmemmap_populate altmap handling In-Reply-To: <20170731125555.GB4829@dhcp22.suse.cz> References: <20170726083333.17754-1-mhocko@kernel.org> <20170726083333.17754-3-mhocko@kernel.org> <20170731144053.38c8b012@thinkpad> <20170731125555.GB4829@dhcp22.suse.cz> Organization: IBM Deutschland Research & Development GmbH / Vorsitzende des Aufsichtsrats: Martina Koederitz / Geschaeftsfuehrung: Dirk Wittkopp / Sitz der Gesellschaft: Boeblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.23; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17073114-0016-0000-0000-000004DD0D5B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17073114-0017-0000-0000-0000281403AE Message-Id: <20170731162746.60b8d98e@thinkpad> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-31_06:,, 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-1706020000 definitions=main-1707310247 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1770 Lines: 41 On Mon, 31 Jul 2017 14:55:56 +0200 Michal Hocko wrote: > On Mon 31-07-17 14:40:53, Gerald Schaefer wrote: > [...] > > > @@ -247,12 +248,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node) > > > * use large frames even if they are only partially > > > * used. > > > * Otherwise we would have also page tables since > > > - * vmemmap_populate gets called for each section > > > + * __vmemmap_populate gets called for each section > > > * separately. */ > > > if (MACHINE_HAS_EDAT1) { > > > void *new_page; > > > > > > - new_page = vmemmap_alloc_block(PMD_SIZE, node); > > > + new_page = __vmemmap_alloc_block_buf(PMD_SIZE, node, altmap); > > > if (!new_page) > > > goto out; > > > pmd_val(*pm_dir) = __pa(new_page) | sgt_prot; > > > > There is another call to vmemmap_alloc_block() in this function, a couple > > of lines below, this should also be replaced by __vmemmap_alloc_block_buf(). > > I've noticed that one but in general I have only transformed PMD > mappings because we shouldn't even get to pte level if the forme works > AFAICS. Memory sections should be always 2MB aligned unless I am missing > something. Or is this not true? vmemmap_populate() on s390 will only stop at pmd level if we have HW support for large pages (MACHINE_HAS_EDAT1). In that case we will allocate a PMD_SIZE block with vmemmap_alloc_block() and map it on pmd level as a large page. Without HW large page support, we will continue to allocate a pte page, populate the pmd entry with that, and fall through to the pte_none() check below, with its PAGE_SIZE vmemmap_alloc_block() allocation. In this case we should use the __vmemmap_alloc_block_buf(). Regards, Gerald