From patchwork Tue Feb 18 10:05:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 11388149 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 64CEF924 for ; Tue, 18 Feb 2020 10:05:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3AAE322B48 for ; Tue, 18 Feb 2020 10:05:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3AAE322B48 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 606FA6B0003; Tue, 18 Feb 2020 05:05:36 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 5B8586B0006; Tue, 18 Feb 2020 05:05:36 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CDF16B0007; Tue, 18 Feb 2020 05:05:36 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id 362D66B0003 for ; Tue, 18 Feb 2020 05:05:36 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C1E8D181AEF1A for ; Tue, 18 Feb 2020 10:05:35 +0000 (UTC) X-FDA: 76502815830.05.can41_30c91d2796249 X-Spam-Summary: 2,0,0,a1202ad5162c424b,d41d8cd98f00b204,mstsxfx@gmail.com,:kkabe@vega.pgw.jp:bhe@redhat.com: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:,RULES_HIT:41:355:379:800:960:968:973:982:988:989:1260:1277:1312:1313:1314:1345:1359:1367:1437:1516:1518:1519:1535:1543:1593:1594:1595:1596:1711:1730:1747:1777:1792:2393:2553:2559:2562:2693:3138:3139:3140:3141:3142:3355:3865:3866:3867:3868:3870:3871:3872:3873:3874:4321:4560:5007:6120:6261:7576:9036:9545:10004:10400:10471:10967:11026:11232:11473:11658:11914:12043:12262:12296:12297:12438:12517:12519:12533:12555:12663:12679:12700:12737:12740:12895:12986:13146:13149:13230:13255:13439:13869:13895:14096:14097:14181:14721:21080:21444:21451:21611:21627:21740:21939:30005:30012:30054:30056:30090:30091,0,RBL:209.85.128.67:@gmail.com:.lbl8.mailshell.net-62.18.0.100 66.100.201.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,Doma inCache: X-HE-Tag: can41_30c91d2796249 X-Filterd-Recvd-Size: 5487 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Feb 2020 10:05:35 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id a5so2133223wmb.0 for ; Tue, 18 Feb 2020 02:05:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=U/XL8qh9M7KUIQL8WnhIhGiOUv2sijJ48c5vtZqppSs=; b=XsoSZLmuuJAZCIuI426d3JPJzJ+ayNwSGyfHv5YG6xe83SpSrHCVFx5sWEkPgEAto7 AV1G9Dfp3BNqt2J2V/BRQTwpUubNdzKnIP24WU5jqIIMHUHx/QPSaq2GnQh0j+v45SRK D6gP64K8cp4G07rcuBrBoYCo0JZzu/1kyAnbCSbMwR490JFOeecmxG8BisWyPDcXFK5y RFhC038bLSZi0bIxhTnmp7pO8H9AVJyGOS1uE+zSaqxJz2tEHZh9ud/VaL67FSOg47v8 bfWi4jVgQ9+wKMStV0BosWxv3Jz/D7oYrtVlZYiBeNeqdeAybns7fx8GyjJNs/G+mmEy KITA== X-Gm-Message-State: APjAAAWo+ULKouLQ522FRUxgnsVtrCj+OLImOT32FN7CAzz3hnyQL0Q6 VDE/Szs6sMFvYA7LrUb11fM= X-Google-Smtp-Source: APXvYqyYpF3AcgCvYiEDkgGJftjiucRFE4KZWYG9pc+dU38bDAwFLsiIcINU2m3VSHaDLld4RycwTw== X-Received: by 2002:a1c:f713:: with SMTP id v19mr2137475wmh.113.1582020334119; Tue, 18 Feb 2020 02:05:34 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id b17sm5451519wrp.49.2020.02.18.02.05.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Feb 2020 02:05:33 -0800 (PST) Date: Tue, 18 Feb 2020 11:05:32 +0100 From: Michal Hocko To: kkabe@vega.pgw.jp Cc: bhe@redhat.com, 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: [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: <20200218100532.GA4151@dhcp22.suse.cz> References: <20200218084700.GD21113@dhcp22.suse.cz> <200218181900.M0115079@vega.pgw.jp> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200218181900.M0115079@vega.pgw.jp> 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 Tue 18-02-20 18:19:00, kkabe@vega.pgw.jp wrote: > mhocko@kernel.org sed in <20200218084700.GD21113@dhcp22.suse.cz> > > >> 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. > >> > >> I was about to post a patch to mark hotplug broken on 32b but it seems > >> you do care about this setup. Could you describe your usecase please? > > 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 requirement. > (as in the anaconda test revealed) OK, thanks for the clarification. I am not sure that this qualifies as a sufficient reason to maintain the code though. > If we're disabling it, we have to announce it somewhere; > where is appropriate? `modinfo hv_balloon`'s "hot_add" description? 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. Acked-by: David Hildenbrand Acked-by: Baoquan He --- 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 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. 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. 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. Signed-off-by: Michal Hocko --- mm/Kconfig | 1 + 1 file changed, 1 insertion(+) 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 bool "Allow for memory hot-add" depends on SPARSEMEM || X86_64_ACPI_NUMA depends on ARCH_ENABLE_MEMORY_HOTPLUG + depends on 64BIT || BROKEN config MEMORY_HOTPLUG_SPARSE def_bool y