From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 203C5C3A5A6 for ; Mon, 23 Sep 2019 10:52:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D940520867 for ; Mon, 23 Sep 2019 10:52:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D940520867 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 886F26B0006; Mon, 23 Sep 2019 06:52:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 828126B0008; Mon, 23 Sep 2019 06:52:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7400F6B000A; Mon, 23 Sep 2019 06:52:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id 4FE186B0006 for ; Mon, 23 Sep 2019 06:52:28 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id E6909D19 for ; Mon, 23 Sep 2019 10:52:27 +0000 (UTC) X-FDA: 75965871534.17.tiger21_89e28e659c619 X-HE-Tag: tiger21_89e28e659c619 X-Filterd-Recvd-Size: 3632 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Mon, 23 Sep 2019 10:52:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7D52AAEE1; Mon, 23 Sep 2019 10:52:25 +0000 (UTC) Date: Mon, 23 Sep 2019 12:52:24 +0200 From: Michal Hocko To: Anshuman Khandual Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Oscar Salvador , David Hildenbrand , Pavel Tatashin , Dan Williams Subject: Re: [PATCH] mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory() Message-ID: <20190923105224.GH6016@dhcp22.suse.cz> References: <1568612857-10395-1-git-send-email-anshuman.khandual@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1568612857-10395-1-git-send-email-anshuman.khandual@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 16-09-19 11:17:37, Anshuman Khandual wrote: > In add_memory_resource() the memory range to be hot added first gets into > the memblock via memblock_add() before arch_add_memory() is called on it. > Reverse sequence should be followed during memory hot removal which already > is being followed in add_memory_resource() error path. This now ensures > required re-order between memblock_[free|remove]() and arch_remove_memory() > during memory hot-remove. This changelog is not really easy to follow. First of all please make sure to explain whether there is any actual problem to solve or this is an aesthetic matter. Please think of people reading this changelog in few years and scratching their heads what you were thinking back then... > Cc: Andrew Morton > Cc: Oscar Salvador > Cc: Michal Hocko > Cc: David Hildenbrand > Cc: Pavel Tatashin > Cc: Dan Williams > Signed-off-by: Anshuman Khandual > --- > Original patch https://lkml.org/lkml/2019/9/3/327 > > Memory hot remove now works on arm64 without this because a recent commit > 60bb462fc7ad ("drivers/base/node.c: simplify unregister_memory_block_under_nodes()"). > > David mentioned that re-ordering should still make sense for consistency > purpose (removing stuff in the reverse order they were added). This patch > is now detached from arm64 hot-remove series. > > https://lkml.org/lkml/2019/9/3/326 > > mm/memory_hotplug.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index c73f09913165..355c466e0621 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1770,13 +1770,13 @@ static int __ref try_remove_memory(int nid, u64 start, u64 size) > > /* remove memmap entry */ > firmware_map_remove(start, start + size, "System RAM"); > - memblock_free(start, size); > - memblock_remove(start, size); > > /* remove memory block devices before removing memory */ > remove_memory_block_devices(start, size); > > arch_remove_memory(nid, start, size, NULL); > + memblock_free(start, size); > + memblock_remove(start, size); > __release_memory_resource(start, size); > > try_offline_node(nid); > -- > 2.20.1 -- Michal Hocko SUSE Labs