On 03/04/2019 18:32, Logan Gunthorpe wrote:
On 2019-04-02 10:30 p.m., Anshuman Khandual wrote:
Memory removal from an arch perspective involves tearing down two different
kernel based mappings i.e vmemmap and linear while releasing related page
table pages allocated for the physical memory range to be removed.
Define a common kernel page table tear down helper remove_pagetable() which
can be used to unmap given kernel virtual address range. In effect it can
tear down both vmemap or kernel linear mappings. This new helper is called
from both vmemamp_free() and ___remove_pgd_mapping() during memory removal.
The argument 'direct' here identifies kernel linear mappings.
Vmemmap mappings page table pages are allocated through sparse mem helper
functions like vmemmap_alloc_block() which does not cycle the pages through
pgtable_page_ctor() constructs. Hence while removing it skips corresponding
destructor construct pgtable_page_dtor().
While here update arch_add_mempory() to handle __add_pages() failures by
just unmapping recently added kernel linear mapping. Now enable memory hot
remove on arm64 platforms by default with ARCH_ENABLE_MEMORY_HOTREMOVE.
This implementation is overall inspired from kernel page table tear down
procedure on X86 architecture.
I've been working on very similar things for RISC-V. In fact, I'm
currently in progress on a very similar stripped down version of
remove_pagetable(). (Though I'm fairly certain I've done a bunch of
stuff wrong.)
Would it be possible to move this work into common code that can be used
by all arches? Seems like, to start, we should be able to support both
arm64 and RISC-V... and maybe even x86 too.
I'd be happy to help integrate and test such functions in RISC-V.
Indeed, I had hoped we might be able to piggyback off generic code for
this anyway, given that we have generic pagetable code which knows how
to free process pagetables, and kernel pagetables are also pagetables.
I did actually hack up such a patch[1], and other than
p?d_none_or_clear_bad() being loud it does actually appear to function
OK in terms of withstanding repeated add/remove cycles and not crashing,
but all the pagetable accounting and other stuff I don't really know
about mean it's probably not viable without a lot more core work.
Robin.
[1]
http://linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=75934a2c4f737ad9f26903861108d5b0658e86bb
