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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 9C47FC433C1 for ; Thu, 25 Mar 2021 14:08:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3B22061962 for ; Thu, 25 Mar 2021 14:08:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B22061962 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C136D6B0070; Thu, 25 Mar 2021 10:08:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B9B6E6B0073; Thu, 25 Mar 2021 10:08:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C7596B0074; Thu, 25 Mar 2021 10:08:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id 7DB036B0070 for ; Thu, 25 Mar 2021 10:08:42 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3553232068 for ; Thu, 25 Mar 2021 14:08:42 +0000 (UTC) X-FDA: 77958577284.35.D51D367 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf08.hostedemail.com (Postfix) with ESMTP id 13D70801AE5C for ; Thu, 25 Mar 2021 14:08:29 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1616681310; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ESAA6ThVbjxDwvrgI7oZbg7SXTWiqqrNoNLZkKKalh4=; b=tzDk5ICtnXG7UJmZ8DpY6U1BkuC8D1+8dPNDnnlOOpvOAWVIxnmuVjMZzsJBnI4o23vNa3 ZfwNLnTDS1jWHUwwFpu2yhiWEI+8YhdGvMEGSKjVyqKi5ykvubchfi/vGyBcQ5scNA72Bp sWuqWpNUXdNN8ormZOk2m/JxOTpwPAw= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 08DEEADAA; Thu, 25 Mar 2021 14:08:30 +0000 (UTC) Date: Thu, 25 Mar 2021 15:08:23 +0100 From: Michal Hocko To: David Hildenbrand Cc: Oscar Salvador , Andrew Morton , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 1/5] mm,memory_hotplug: Allocate memmap from the added memory range Message-ID: References: <3bc4168c-fd31-0c9a-44ac-88e25d524eef@redhat.com> <9591a0b8-c000-2f61-67a6-4402678fe50b@redhat.com> <31110e58-c99a-8dee-6f6e-98f456b77759@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31110e58-c99a-8dee-6f6e-98f456b77759@redhat.com> X-Stat-Signature: tpasi97p6pb145hyg8fa9znupjjyrhde X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 13D70801AE5C Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616681309-21804 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 Thu 25-03-21 13:40:45, David Hildenbrand wrote: > On 25.03.21 13:35, Michal Hocko wrote: > > On Thu 25-03-21 12:08:43, David Hildenbrand wrote: > > > On 25.03.21 11:55, Oscar Salvador wrote: [...] > > > > - When moving the initialization/accounting to hot-add/hot-remove, > > > > the section containing the vmemmap pages will remain offline. > > > > It might get onlined once the pages get online in online_pages(), > > > > or not if vmemmap pages span a whole section. > > > > I remember (but maybe David rmemeber better) that that was a problem > > > > wrt. pfn_to_online_page() and hybernation/kdump. > > > > So, if that is really a problem, we would have to care of ot setting > > > > the section to the right state. > > > > > > Good memory. Indeed, hibernation/kdump won't save the state of the vmemmap, > > > because the memory is marked as offline and, thus, logically without any > > > valuable content. > > > > Could you point me to the respective hibernation code please? I always > > get lost in that area. Anyway, we do have the same problem even if the > > whole accounting is handled during {on,off}lining, no? > > kernel/power/snapshot.c:saveable_page(). Thanks! So this is as I've suspected. The very same problem is present if the memory block is marked offline. So we need a solution here anyway. One way to go would be to consider these vmemmap pages always online. pfn_to_online_page would have to special case them but we would need to identify them first. I used to have PageVmemmap or something like that in my early attempt to do this. That being said this is not an argument for one or the other aproach. Both need fixing. -- Michal Hocko SUSE Labs