Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4244528yba; Tue, 7 May 2019 14:52:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqzVBCGchlg09w/6x4tl07K12IKw6x238Oxs2yJmSAlXlv/VdeQPataL8nA8F2OHzNco9Xu/ X-Received: by 2002:a65:63c8:: with SMTP id n8mr7876467pgv.96.1557265957727; Tue, 07 May 2019 14:52:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557265957; cv=none; d=google.com; s=arc-20160816; b=ZOVKgQ8DiaGDHN3DavLZar17UAgO/caRsTAwVthI+rIDfGWRpz82TDT+sCBNpBkfXe K0Tps1PO7GrlBHHK8sGdOZmmG0x7ECakSC050ul1cWLJFehr/3S7H508lp4Fa3e3d8QD RH26mCyioTCPlNn8t8Q+2S0FkEttGqbOHZDI6UGl4frVik3+8+rAUm0JJXoWB3OJBkLC AGZHeZmTCzhjaf8NqgDl4kff5BdSsRZF6KrUoRQ8zihhMepsAh2/YDS4P2m6uM8Zbwfy CKg9P3VReLeHy8g3RRWx8DlMSH0099dSNQEQUObVAzWuG7tcXMlLCuR0v/v17+DU1Uck xrfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=3hK5kgswQ8wv2TZkCFoSuWyjsyMg02YpSTLcE/+WG/U=; b=I8JAPsrtD4dmt4vt/jAxtWfOOHm+/9RJgv3EP3AQY3gY6D+Pd2Rg25z0fkQES1dXIy b+OnyBbh9A/X9mjclkmCBM4bAvxLpRfw8uWuDrPIimWcmZwxnce7/ko93rfViG1a9pOW Pi2P62K7JrIdzlgXWgytbfgOz4HUMCgmQeOsE419bzat7BBdOto6EDY1pOw45EjZ5Aoa TBpFNM35tXkyMIshvaYXjzkXShxF/28LcYJdInBMEQB2wr3O3jxoN3P2hkgInZCAx2lN C5Hzfqaj78LG1jHlE6aZiUDtW5CnAuvQtkR1UoLyPxjOC3Vv7tKT+82+jLCBWF3DQqbt ydIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="JB3/ofVK"; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c15si18031989pgl.160.2019.05.07.14.52.22; Tue, 07 May 2019 14:52:37 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="JB3/ofVK"; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728575AbfEGVTe (ORCPT + 99 others); Tue, 7 May 2019 17:19:34 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:35068 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727278AbfEGVTd (ORCPT ); Tue, 7 May 2019 17:19:33 -0400 Received: by mail-ot1-f68.google.com with SMTP id g24so16421630otq.2 for ; Tue, 07 May 2019 14:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3hK5kgswQ8wv2TZkCFoSuWyjsyMg02YpSTLcE/+WG/U=; b=JB3/ofVKMzM47vp5cpkgsnhZ8ZoLv1EVoO9+f31886li2wtHIqmVJSjWZgBJwXVWkQ BX8fXeuRngRf/Ks+w1ntTvElqYBed9sGLskf82OMafAfaVt9JAi0cGsgfLfsvJoqqDNr leYUf1Qr603j9SX7YPOMJQJ/cTCjxhAKYRdtUuxeKEq3ug1IPoCPnsVf+3r99jUb+zmR INxH8W2mrFhA3n0T4xrdVH8dH6T52i5DTkq3iyhP8i9MzOP7NEL5WL7OGtJR7yWG5TTZ DDa00gAnvg3r1yMN6dj4XSo/K//hjnmaEZqeXhVR8JHWgv3lVtO0ckrsHunC8Zyn08k4 ovPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3hK5kgswQ8wv2TZkCFoSuWyjsyMg02YpSTLcE/+WG/U=; b=sHLJJwl8h9Ml/Fu64lUBPj51xDcCpJJtxDOhMcc+ure/4mJdmMTityIe+SepPxX1W0 5eoNRwOpWxVXZo4ae7rPJyd8rtSr1JkXcHboChZdniDmBAAgyqUA/CJwqHxJsM8OBAqF RSrfvAwn2OJVtXcEQ2XKnRJDz0+x75kYuT08t+B2YUmg7cQgekqFm+AJwZNCiUrLekB3 Z3DOJ6JMILlfJ2DWpmHEkEJ0tuMB340TKBE17s3RUiMNbqtC2AJu5TovTEkHLFDEvmy9 Jv5z0q41Idn7lDT7/WHn1rkleKYkni0Qbl1eK1AZOIXs76kKQ4yFCnHnWef6ZdOF0kQt ajIQ== X-Gm-Message-State: APjAAAVuQssd8m0yhqv3xUZdUvDor+CFjfKZ54y5tFGQIdFJGXq4J+Tn xQWtZU3sz+DQdpq37ynh7oMtTqj31JT5C91CTrLkgA== X-Received: by 2002:a9d:222c:: with SMTP id o41mr23286782ota.353.1557263973069; Tue, 07 May 2019 14:19:33 -0700 (PDT) MIME-Version: 1.0 References: <20190507183804.5512-1-david@redhat.com> <20190507183804.5512-6-david@redhat.com> In-Reply-To: <20190507183804.5512-6-david@redhat.com> From: Dan Williams Date: Tue, 7 May 2019 14:19:22 -0700 Message-ID: Subject: Re: [PATCH v2 5/8] mm/memory_hotplug: Drop MHP_MEMBLOCK_API To: David Hildenbrand Cc: Linux MM , Linux Kernel Mailing List , linux-ia64@vger.kernel.org, linuxppc-dev , linux-s390 , Linux-sh , Andrew Morton , Michal Hocko , Oscar Salvador , Pavel Tatashin , Wei Yang , Joonsoo Kim , Qian Cai , Arun KS , Mathieu Malaterre Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote: > > No longer needed, the callers of arch_add_memory() can handle this > manually. > > Cc: Andrew Morton > Cc: David Hildenbrand > Cc: Michal Hocko > Cc: Oscar Salvador > Cc: Pavel Tatashin > Cc: Wei Yang > Cc: Joonsoo Kim > Cc: Qian Cai > Cc: Arun KS > Cc: Mathieu Malaterre > Signed-off-by: David Hildenbrand > --- > include/linux/memory_hotplug.h | 8 -------- > mm/memory_hotplug.c | 9 +++------ > 2 files changed, 3 insertions(+), 14 deletions(-) > > diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h > index 2d4de313926d..2f1f87e13baa 100644 > --- a/include/linux/memory_hotplug.h > +++ b/include/linux/memory_hotplug.h > @@ -128,14 +128,6 @@ extern void arch_remove_memory(int nid, u64 start, u64 size, > extern void __remove_pages(struct zone *zone, unsigned long start_pfn, > unsigned long nr_pages, struct vmem_altmap *altmap); > > -/* > - * Do we want sysfs memblock files created. This will allow userspace to online > - * and offline memory explicitly. Lack of this bit means that the caller has to > - * call move_pfn_range_to_zone to finish the initialization. > - */ > - > -#define MHP_MEMBLOCK_API (1<<0) > - > /* reasonably generic interface to expand the physical pages */ > extern int __add_pages(int nid, unsigned long start_pfn, unsigned long nr_pages, > struct mhp_restrictions *restrictions); > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index e1637c8a0723..107f72952347 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -250,7 +250,7 @@ void __init register_page_bootmem_info_node(struct pglist_data *pgdat) > #endif /* CONFIG_HAVE_BOOTMEM_INFO_NODE */ > > static int __meminit __add_section(int nid, unsigned long phys_start_pfn, > - struct vmem_altmap *altmap, bool want_memblock) > + struct vmem_altmap *altmap) > { > int ret; > > @@ -293,8 +293,7 @@ int __ref __add_pages(int nid, unsigned long phys_start_pfn, > } > > for (i = start_sec; i <= end_sec; i++) { > - err = __add_section(nid, section_nr_to_pfn(i), altmap, > - restrictions->flags & MHP_MEMBLOCK_API); > + err = __add_section(nid, section_nr_to_pfn(i), altmap); > > /* > * EEXIST is finally dealt with by ioresource collision > @@ -1066,9 +1065,7 @@ static int online_memory_block(struct memory_block *mem, void *arg) > */ > int __ref add_memory_resource(int nid, struct resource *res) > { > - struct mhp_restrictions restrictions = { > - .flags = MHP_MEMBLOCK_API, > - }; > + struct mhp_restrictions restrictions = {}; With mhp_restrictions.flags no longer needed, can we drop mhp_restrictions and just go back to a plain @altmap argument?