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.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 02F1DC3402F for ; Wed, 19 Feb 2020 03:23:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BBAD624655 for ; Wed, 19 Feb 2020 03:23:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZEHF8ECF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BBAD624655 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6937F6B000A; Tue, 18 Feb 2020 22:23:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 62EB96B000C; Tue, 18 Feb 2020 22:23:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 544156B000D; Tue, 18 Feb 2020 22:23:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0152.hostedemail.com [216.40.44.152]) by kanga.kvack.org (Postfix) with ESMTP id 3CFD66B000A for ; Tue, 18 Feb 2020 22:23:31 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C27548248047 for ; Wed, 19 Feb 2020 03:23:30 +0000 (UTC) X-FDA: 76505431380.09.knee31_58d51272e1b00 X-HE-Tag: knee31_58d51272e1b00 X-Filterd-Recvd-Size: 6174 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Feb 2020 03:23:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582082610; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r7+421qcy5ATlLjTNxLodNa9cTXqfgvHah6c7nxaggk=; b=ZEHF8ECFYJufQRn5EcWvEJov/uNlAq0L5pr1euFQI2f4sISWpo8Kaq4VfDMdXz/OxNB0MQ S6awFi1zwlJ9WMlkmKRzLO6WPSbBCvPi8BczTtaiVsRpt6UnOSGMYne6U8dD7CYA3gjssl Jhxs5sy4A0dT7b2uYxxvh1khHya36cM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-429-4BDsxAAlP3Cue7LSPMxbXA-1; Tue, 18 Feb 2020 22:23:26 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5314C800D48; Wed, 19 Feb 2020 03:23:24 +0000 (UTC) Received: from localhost (ovpn-12-16.pek2.redhat.com [10.72.12.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AFAD860BE1; Wed, 19 Feb 2020 03:23:20 +0000 (UTC) Date: Wed, 19 Feb 2020 11:23:18 +0800 From: Baoquan He To: Michal Hocko Cc: kkabe@vega.pgw.jp, david@redhat.com, osalvador@suse.de, bugzilla-daemon@bugzilla.kernel.org, akpm@linux-foundation.org, richardw.yang@linux.intel.com, n-horiguchi@ah.jp.nec.com, linux-mm@kvack.org Subject: Re: [RFC PATCH] memory_hotplug: disable the functionality for 32b (was: Re: [Bug 206401] kernel panic on Hyper-V after 5 minutes due to) memory hot-add Message-ID: <20200219032318.GA4937@MiWiFi-R3L-srv> References: <20200218084700.GD21113@dhcp22.suse.cz> <200218181900.M0115079@vega.pgw.jp> <20200218100532.GA4151@dhcp22.suse.cz> MIME-Version: 1.0 In-Reply-To: <20200218100532.GA4151@dhcp22.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-MC-Unique: 4BDsxAAlP3Cue7LSPMxbXA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 02/18/20 at 11:05am, Michal Hocko wrote: > On Tue 18-02-20 18:19:00, kkabe@vega.pgw.jp wrote: > > mhocko@kernel.org sed in <20200218084700.GD21113@dhcp22.suse.cz> > >=20 > > >> On Tue 18-02-20 15:24:48, kkabe@vega.pgw.jp wrote: > > >> [...] > > >> > Tried out the above patch. > > >> > It seems to be working; no panic, total memory has increased and > > >> > the hot-added memory is added as HIGHMEM. > > >>=20 > > >> I was about to post a patch to mark hotplug broken on 32b but it see= ms > > >> you do care about this setup. Could you describe your usecase please= ? > >=20 > > My usecase is testing out the kernel on Hyper-V before loading it on > > real i686 machine. Hyper-V machine is faster to skim out other bugs. > > So memory hot-add is not a must requirement for me, > > but having hot-add may be handy to see the application memory requireme= nt. > > (as in the anaconda test revealed) >=20 > OK, thanks for the clarification. I am not sure that this qualifies > as a sufficient reason to maintain the code though. >=20 > > If we're disabling it, we have to announce it somewhere; > > where is appropriate? `modinfo hv_balloon`'s "hot_add" description? >=20 > This should behave the same way as when the CONFIG_MEMORY_HOTPLULG is > not enabled. And from a very cursory look hv_balloon.c already checks > for the config. >=20 > --- > From 562f21abeda508f199c34358e50fbaa518cd5ed8 Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Tue, 18 Feb 2020 08:04:13 +0100 > Subject: [PATCH] memory_hotplug: disable the functionality for 32b >=20 > Memory hotlug is broken for 32b systems at least since c6f03e2903c9 > ("mm, memory_hotplug: remove zone restrictions") which has considerably > reworked how can be memory associated with movable/kernel zones. The > same is not really trivial to achieve in 32b where only lowmem is the > kernel zone. While we can tweak this immediate problem around there are > likely other land mines hidden at other places. >=20 > It is also quite dubious that there is a real usecase for the memory > hotplug on 32b in the first place. Low memory is just too small to be > hotplugable (for hot add) and generally unusable for hotremove. Adding > more memory to highmem is also dubious because it would increase the > low mem or vmalloc space pressure for memmaps. >=20 > Restrict the functionality to 64b systems. This will help future > development to focus on usecases that have real life application. We > can remove this restriction in future in presence of a real life usecase > of course but until then make it explicit that hotplug on 32b is broken > and requires a non trivial amount of work to fix. >=20 > Signed-off-by: Michal Hocko No objection to this, ack. Acked-by: Baoquan He At least in our distros, we have taken the i386 off from our ARCH lists for a very long time, hence I personally haven't followed i386 code for a long time either. This can save our time when maintain the mem hotplug code. Thanks for making this patch. Thanks Baoquan > --- > mm/Kconfig | 1 + > 1 file changed, 1 insertion(+) >=20 > diff --git a/mm/Kconfig b/mm/Kconfig > index ab80933be65f..2d5fe9e92969 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -154,6 +154,7 @@ config MEMORY_HOTPLUG > =09bool "Allow for memory hot-add" > =09depends on SPARSEMEM || X86_64_ACPI_NUMA > =09depends on ARCH_ENABLE_MEMORY_HOTPLUG > +=09depends on 64BIT || BROKEN > =20 > config MEMORY_HOTPLUG_SPARSE > =09def_bool y > --=20 > 2.24.1 >=20 > --=20 > Michal Hocko > SUSE Labs >=20