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=-3.8 required=3.0 tests=BAYES_00, 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 C8D42C433DB for ; Mon, 8 Mar 2021 14:05:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4C44C6512B for ; Mon, 8 Mar 2021 14:05:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C44C6512B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B82466B00D5; Mon, 8 Mar 2021 09:05:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B0C1B6B00D6; Mon, 8 Mar 2021 09:05:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 985466B00D7; Mon, 8 Mar 2021 09:05:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) by kanga.kvack.org (Postfix) with ESMTP id 793F46B00D5 for ; Mon, 8 Mar 2021 09:05:02 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3A8D18249980 for ; Mon, 8 Mar 2021 14:05:02 +0000 (UTC) X-FDA: 77896878444.14.F8BC16E Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf29.hostedemail.com (Postfix) with ESMTP id 219F223B1 for ; Mon, 8 Mar 2021 14:04:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8D379ADDB; Mon, 8 Mar 2021 14:04:53 +0000 (UTC) Date: Mon, 8 Mar 2021 15:04:51 +0100 From: Oscar Salvador To: Zi Yan Cc: Andrew Morton , David Hildenbrand , Michal Hocko , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Kravetz Subject: Re: [PATCH v3 1/5] mm,memory_hotplug: Allocate memmap from the added memory range Message-ID: References: <20210304100002.7740-1-osalvador@suse.de> <20210304100002.7740-2-osalvador@suse.de> <830F715B-82B4-4A13-861F-B3A89327F722@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <830F715B-82B4-4A13-861F-B3A89327F722@nvidia.com> X-Stat-Signature: cg5k59mordohputa3e86qx5hrgdgbiau X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 219F223B1 Received-SPF: none (suse.de>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1615212295-473552 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 Sun, Mar 07, 2021 at 10:16:36PM -0500, Zi Yan wrote: > +Mike for hugetlb discussion. > > Just thinking about how it might impact gigantic page allocation like hugetlb. > When MHP_MEMMAP_ON_MEMORY is on, memmap pages are placed at the beginning > of each hot added memory block, so available PFNs from two consecutive > hot added memory blocks are not all contiguous, separated by memmap pages. > If the memory block size is <= 1GB, there is no way of reserving gigantic > pages for hugetlb during runtime using alloc_contig_pages from any hot > added memory. Am I getting this right? Yes, that is why it is stated both in boot parameter documentation and patch changelog that this feature does not play well in those setups where your workload is in need of large contiguous chunks of memory, that being gigantic hugetlb or just normal memory. > I see this implication is documented at the high level in patch 3. Just > wonder if we want to be more specific. Or hugetlb is rarely used along > with hot-add memory. I think it is quite normal to see hugetlb and hotplug operations in the same environment. One thing excludes the other, just need to be careful when it comes to potential pitfalls during offline operations. I guess we could mention hugetlb pages in the documentation, if it feels it is necesary. -- Oscar Salvador SUSE L3