From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f67.google.com ([209.85.208.67]:34499 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725956AbfFCVln (ORCPT ); Mon, 3 Jun 2019 17:41:43 -0400 Date: Mon, 3 Jun 2019 21:41:39 +0000 From: Wei Yang Subject: Re: [PATCH v3 04/11] arm64/mm: Add temporary arch_remove_memory() implementation Message-ID: <20190603214139.mercn5hol2yyfl2s@master> Reply-To: Wei Yang References: <20190527111152.16324-1-david@redhat.com> <20190527111152.16324-5-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190527111152.16324-5-david@redhat.com> Sender: linux-s390-owner@vger.kernel.org List-ID: To: David Hildenbrand Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, Dan Williams , Wei Yang , Igor Mammedov , Catalin Marinas , Will Deacon , Mark Rutland , Ard Biesheuvel , Chintan Pandya , Mike Rapoport , Jun Yao , Yu Zhao , Robin Murphy , Anshuman Khandual On Mon, May 27, 2019 at 01:11:45PM +0200, David Hildenbrand wrote: >A proper arch_remove_memory() implementation is on its way, which also >cleanly removes page tables in arch_add_memory() in case something goes >wrong. Would this be better to understand? removes page tables created in arch_add_memory > >As we want to use arch_remove_memory() in case something goes wrong >during memory hotplug after arch_add_memory() finished, let's add >a temporary hack that is sufficient enough until we get a proper >implementation that cleans up page table entries. > >We will remove CONFIG_MEMORY_HOTREMOVE around this code in follow up >patches. > >Cc: Catalin Marinas >Cc: Will Deacon >Cc: Mark Rutland >Cc: Andrew Morton >Cc: Ard Biesheuvel >Cc: Chintan Pandya >Cc: Mike Rapoport >Cc: Jun Yao >Cc: Yu Zhao >Cc: Robin Murphy >Cc: Anshuman Khandual >Signed-off-by: David Hildenbrand >--- > arch/arm64/mm/mmu.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > >diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c >index a1bfc4413982..e569a543c384 100644 >--- a/arch/arm64/mm/mmu.c >+++ b/arch/arm64/mm/mmu.c >@@ -1084,4 +1084,23 @@ int arch_add_memory(int nid, u64 start, u64 size, > return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT, > restrictions); > } >+#ifdef CONFIG_MEMORY_HOTREMOVE >+void arch_remove_memory(int nid, u64 start, u64 size, >+ struct vmem_altmap *altmap) >+{ >+ unsigned long start_pfn = start >> PAGE_SHIFT; >+ unsigned long nr_pages = size >> PAGE_SHIFT; >+ struct zone *zone; >+ >+ /* >+ * FIXME: Cleanup page tables (also in arch_add_memory() in case >+ * adding fails). Until then, this function should only be used >+ * during memory hotplug (adding memory), not for memory >+ * unplug. ARCH_ENABLE_MEMORY_HOTREMOVE must not be >+ * unlocked yet. >+ */ >+ zone = page_zone(pfn_to_page(start_pfn)); Compared with arch_remove_memory in x86. If altmap is not NULL, zone will be retrieved from page related to altmap. Not sure why this is not the same? >+ __remove_pages(zone, start_pfn, nr_pages, altmap); >+} >+#endif > #endif >-- >2.20.1 -- Wei Yang Help you, Help me