Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp414123yba; Wed, 3 Apr 2019 11:09:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqysbUEjlUBSvHnc+zpiqJKKPmKXErQPy5g5DcLzDMrTce0Lf7qeEUYe49Qe7CYoSIPiwU9H X-Received: by 2002:a63:f218:: with SMTP id v24mr1116969pgh.326.1554314999136; Wed, 03 Apr 2019 11:09:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554314999; cv=none; d=google.com; s=arc-20160816; b=uDZT4DC3l3INT3hu1icJprf0HUAKwohodZ3n7jlUFJshV6QeprvNZH1WZMX5aJiaLS xzGYmp7JVv+aw2HKkQiqNklICbIJ6Ayz/S0HWNnTCzQEFZ/2S5dwRInm5eG4MdySmUQq mq8tkU8EjFYd3JIdBWBehWsU8nHMDneL/kqoAgVVF3CrLknItfhn1hJMXum2T8DCAoeE uDMogAgxp0BXkD4qPaqGiLDEWf8YpCzQUIKZcyCDJLxrg6B2zGgQruABVGpRf97O7RlY WASoZWjroB/1ZaG0F4H9wV5B1VqkNfItwXvyNJvHvs0gSYFmbpMpH4kx++tfI3zAigkA fVCw== 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=WLfeTHYa0RD16P6+TGw1835NRm1Z2mjwVm5mp+9PwC4=; b=hMWgfJA3Nf2yfK9J/KuPyBjJtJaWhmq+SLxtPnsKu97ndRf6prUOWiNnMDbxMjULye kepbUUINYMl2SEefKlh1/DW36uD+oVYXI8cq7CYDCabHg71jj8nhejvJKShsbwuGt6Xc OVmT9Jf4BpA8VaGz1EXl/W7MBgSooSn7eoO4lLkGJWpn7WP8OvLh1O1NSx+Ec0S0x1X7 J/1PW654fk/7sYnhFEmxqLS5GwRP5QIi3Jv2cdQZK9z38mTG2kvpbRHefffrhDLw8aoi r1tK8OAfWQwW1bjP+QeK3Ec3qHTnE8osytwdBP7JEkbiHXdUG8NPhu8cscUgvLoSqVZu xvqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=z8K+qZbK; 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 h6si13685636pgv.302.2019.04.03.11.09.43; Wed, 03 Apr 2019 11:09:59 -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=z8K+qZbK; 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 S1726193AbfDCSJG (ORCPT + 99 others); Wed, 3 Apr 2019 14:09:06 -0400 Received: from mail-oi1-f196.google.com ([209.85.167.196]:34624 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726099AbfDCSJF (ORCPT ); Wed, 3 Apr 2019 14:09:05 -0400 Received: by mail-oi1-f196.google.com with SMTP id v10so14394924oib.1 for ; Wed, 03 Apr 2019 11:09:05 -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=WLfeTHYa0RD16P6+TGw1835NRm1Z2mjwVm5mp+9PwC4=; b=z8K+qZbKKB0CPbds0ctgzT6yvbDSyne4jzF+g9MQDqHCPB5OPh0qk2XXWxoiT8uT9G zzAZBBgiwvP3s3WO+yER7TdXgooNtVJn+bJrYtKWk0AUmM4gMN9g2NYXSa+GjS+RD4qh 8xENTTZm8SgBjQ9esMCmbOP5N89LgbdkK2DEsHPY7bvoNzu4jgR80ZG3HLSzPxh0WrY5 S0JNoxdJG64cPYngeWk+znmXW9+iCzcbLOjAVOekrPZVxNPgEekx0LW/gdB8hbrAEi1G xsvjGauCjnbGtT2gFDUKoUQw5H1XawOs5hYrgAV4dxTSwt6qZz7tP5wZXt4VslUi4kvi mGuA== 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=WLfeTHYa0RD16P6+TGw1835NRm1Z2mjwVm5mp+9PwC4=; b=oPEO4b5T3LBLSft58XQWsWOr/U9pn1eLhla2PLqseS2+k4YdLS4j8rXiO2npvFdJkZ kMNbIsxely8ALouyOTfsUjx1veZu96wgcVHsrJU4qj6OKxqSjU/zaV+LfyuyE3UvhwiI J33PAq/rZBwYIzvTkexNHr2X7YkW79vhwO6xkHMh6SVpx7RZgG3Yl4ILINITGQMMoH0y p5d8EyU05oOI2u+GP1Gpu4OabN/Vdv+wH+jTV15esnbPlM3gu3Oi8KQzrsuDbla60OO0 S1mY8UOgzs/D3ZuH5cZ4cmIKu2c1IMLL02MyH6ZEeGe9qqeRMTpkXrc3Dx5u3qBSjzj5 54ww== X-Gm-Message-State: APjAAAVaZVOxdsMh8vzfP0uZlDvNdgzwnk2XoQvbDbKrAXm40ex/e9W1 /h8UYW2El5rV7+RLkHPEmqPkmUgzgx+KmsJnm1N/Cw== X-Received: by 2002:aca:f581:: with SMTP id t123mr589000oih.0.1554314944750; Wed, 03 Apr 2019 11:09:04 -0700 (PDT) MIME-Version: 1.0 References: <1554265806-11501-1-git-send-email-anshuman.khandual@arm.com> In-Reply-To: <1554265806-11501-1-git-send-email-anshuman.khandual@arm.com> From: Dan Williams Date: Wed, 3 Apr 2019 11:08:53 -0700 Message-ID: Subject: Re: [PATCH 0/6] arm64/mm: Enable memory hot remove and ZONE_DEVICE To: Anshuman Khandual Cc: Linux Kernel Mailing List , linux-arm-kernel@lists.infradead.org, Linux MM , Andrew Morton , Will Deacon , Catalin Marinas , Michal Hocko , Mel Gorman , james.morse@arm.com, Mark Rutland , Robin Murphy , cpandya@codeaurora.org, arunks@codeaurora.org, osalvador@suse.de, Logan Gunthorpe , Pavel Tatashin , David Hildenbrand , cai@lca.pw 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, Apr 2, 2019 at 9:30 PM Anshuman Khandual wrote: > > This series enables memory hot remove on arm64, fixes a memblock removal > ordering problem in generic __remove_memory(), enables sysfs memory probe > interface on arm64. It also enables ZONE_DEVICE with struct vmem_altmap > support. > > Testing: > > Tested hot remove on arm64 for all 4K, 16K, 64K page config options with > all possible VA_BITS and PGTABLE_LEVELS combinations. Tested ZONE_DEVICE > with ARM64_4K_PAGES through a dummy driver. > > Build tested on non arm64 platforms. I will appreciate if folks can test > arch_remove_memory() re-ordering in __remove_memory() on other platforms. > > Dependency: > > V5 series in the thread (https://lkml.org/lkml/2019/2/14/1096) will make > kernel linear mapping loose pgtable_page_ctor() init. When this happens > the proposed functions free_pte|pmd|pud_table() in [PATCH 2/6] will have > to stop calling pgtable_page_dtor(). Hi Anshuman, I'd be interested to integrate this with the sub-section hotplug support [1]. Otherwise the padding implementation in libnvdimm can't be removed unless all ZONE_DEVICE capable archs also agree on the minimum arch_add_memory() granularity. I'd prefer not to special case which archs support which granularity, but it unfortunately complicates what you're trying to achieve. I think at a minimum we, mm hotplug co-travellers, need to come to a consensus on whether sub-section support is viable for v5.2 and / or a pre-requisite for new arch-ZONE_DEVICE implementations.