[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4gdz7L20nSMEBNLDWgUzr-GjaBhecF3i8Q4D_O=ug0qNw@mail.gmail.com>
Date: Wed, 3 Apr 2019 11:08:53 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arm-kernel@...ts.infradead.org,
Linux MM <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Will Deacon <will.deacon@....com>,
Catalin Marinas <catalin.marinas@....com>,
Michal Hocko <mhocko@...e.com>,
Mel Gorman <mgorman@...hsingularity.net>, james.morse@....com,
Mark Rutland <mark.rutland@....com>,
Robin Murphy <robin.murphy@....com>, cpandya@...eaurora.org,
arunks@...eaurora.org, osalvador@...e.de,
Logan Gunthorpe <logang@...tatee.com>,
Pavel Tatashin <pasha.tatashin@...cle.com>,
David Hildenbrand <david@...hat.com>, cai@....pw
Subject: Re: [PATCH 0/6] arm64/mm: Enable memory hot remove and ZONE_DEVICE
On Tue, Apr 2, 2019 at 9:30 PM Anshuman Khandual
<anshuman.khandual@....com> 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.
Powered by blists - more mailing lists