Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp248591imm; Tue, 24 Jul 2018 18:19:32 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc0i8z6qvnEjBTtJDPzDoKAJyFDY3eV9xuzaV8P9liIjakDK8dQ1wLlxgR1NuBtcDJksnxz X-Received: by 2002:a63:5c7:: with SMTP id 190-v6mr17939483pgf.385.1532481572935; Tue, 24 Jul 2018 18:19:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532481572; cv=none; d=google.com; s=arc-20160816; b=Zni4NVAPIHrQIIzz1zVOPBe9Jez7HY8Z5GyErL9BUlb6yqK8BPFfq2js2Nhq0O6EFS EkKIW4xlRSskBMzyDnPyZCiUAzD1eICFdarb56CrqpwxSzBpJGhcgi9hMXrkYEpLGmrA RgACvYosr3o78GaWQSqlHbwOgNk1rpKiUewgE68lhu3eOGgsGNIAqB2CjyAhf25ytsfu krIssTzAvOC1IYWH6auFOkIkkZCWr12t27zZ7S5U7IbcXMDmFISqQ5NUCJ7XM8FwYZu7 1JLXeyRHBwZzLe1wgzJUh3ZbuzhwaQtIKmlkbugc+m2gJIQcjOvsoteesGYF1TRpyBtD AIuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=GioRlamP2FwVKsU1E8A8WSrKKlB4c5VWhY+AuyWAs84=; b=C/MowPg9frbBgyCaU1yBUj6CGAkcPosqgwvb0QFT23SWLkso9csqO4mlfAQjETtdV5 cyQmmC16V5SiwzcB2/9zyIFn2nQuTQS/NRT+o4nZa2RFf/HiyPmh2zmO7M57DwtivZJ9 dIvVQGFkI07PI1GzX+CO9llNcyfaW1UzoWYb63oc+BCbh5fYOUc3SFjhGl6Uzc5hTsTy QsEHxyQlFoei0lsJ7F51UCJZRsq/obOp1GJbCrch++DhFfUdcgtsVm2OPOvAHB7/osfh jMBveeRLM9WIPEIFGfMZq1et1cZ0xhUoVUsl1dtoR09HYiifEEPQtFS8FlIBgNcyhZM4 pNwQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h1-v6si11724640pld.485.2018.07.24.18.19.18; Tue, 24 Jul 2018 18:19:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388535AbeGYC1N (ORCPT + 99 others); Tue, 24 Jul 2018 22:27:13 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:32776 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388485AbeGYC1N (ORCPT ); Tue, 24 Jul 2018 22:27:13 -0400 Received: from localhost.localdomain (c-24-4-125-7.hsd1.ca.comcast.net [24.4.125.7]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 80415DC0; Wed, 25 Jul 2018 01:18:02 +0000 (UTC) Date: Tue, 24 Jul 2018 18:18:00 -0700 From: Andrew Morton To: Pavel Tatashin Cc: steven.sistare@oracle.com, daniel.m.jordan@oracle.com, linux-kernel@vger.kernel.org, kirill.shutemov@linux.intel.com, mhocko@suse.com, linux-mm@kvack.org, dan.j.williams@intel.com, jack@suse.cz, jglisse@redhat.com, jrdr.linux@gmail.com, bhe@redhat.com, gregkh@linuxfoundation.org, vbabka@suse.cz, richard.weiyang@gmail.com, dave.hansen@intel.com, rientjes@google.com, mingo@kernel.org, osalvador@techadventures.net, abdhalee@linux.vnet.ibm.com, mpe@ellerman.id.au Subject: Re: [PATCH 3/3] mm: move mirrored memory specific code outside of memmap_init_zone Message-Id: <20180724181800.3f25fdf8bcf0d8fd05ea1f43@linux-foundation.org> In-Reply-To: <20180724235520.10200-4-pasha.tatashin@oracle.com> References: <20180724235520.10200-1-pasha.tatashin@oracle.com> <20180724235520.10200-4-pasha.tatashin@oracle.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 24 Jul 2018 19:55:20 -0400 Pavel Tatashin wrote: > memmap_init_zone, is getting complex, because it is called from different > contexts: hotplug, and during boot, and also because it must handle some > architecture quirks. One of them is mirroed memory. > > Move the code that decides whether to skip mirrored memory outside of > memmap_init_zone, into a separate function. Conflicts a bit with the page_alloc.c hunk from http://ozlabs.org/~akpm/mmots/broken-out/mm-page_alloc-remain-memblock_next_valid_pfn-on-arm-arm64.patch. Please check my fixup: void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone, unsigned long start_pfn, enum memmap_context context, struct vmem_altmap *altmap) { unsigned long pfn, end_pfn = start_pfn + size; struct page *page; if (highest_memmap_pfn < end_pfn - 1) highest_memmap_pfn = end_pfn - 1; /* * Honor reservation requested by the driver for this ZONE_DEVICE * memory */ if (altmap && start_pfn == altmap->base_pfn) start_pfn += altmap->reserve; for (pfn = start_pfn; pfn < end_pfn; pfn++) { /* * There can be holes in boot-time mem_map[]s handed to this * function. They do not exist on hotplugged memory. */ if (context == MEMMAP_EARLY) { if (!early_pfn_valid(pfn)) { pfn = next_valid_pfn(pfn) - 1; continue; } if (!early_pfn_in_nid(pfn, nid)) continue; if (overlap_memmap_init(zone, &pfn)) continue; if (defer_init(nid, pfn, end_pfn)) break; } page = pfn_to_page(pfn); __init_single_page(page, pfn, zone, nid); if (context == MEMMAP_HOTPLUG) SetPageReserved(page); /* * Mark the block movable so that blocks are reserved for * movable at startup. This will force kernel allocations * to reserve their blocks rather than leaking throughout * the address space during boot when many long-lived * kernel allocations are made. * * bitmap is created for zone's valid pfn range. but memmap * can be created for invalid pages (for alignment) * check here not to call set_pageblock_migratetype() against * pfn out of zone. */ if (!(pfn & (pageblock_nr_pages - 1))) { set_pageblock_migratetype(page, MIGRATE_MOVABLE); cond_resched(); } } }