Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1772667pxb; Mon, 8 Mar 2021 06:09:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJxfw8zbpSTY63JeCcUoRvcXiBbuZX9rmtJNVezQenwDzQuGg+J8Ium7CLtReTEzCjoOoj/u X-Received: by 2002:aa7:ccd7:: with SMTP id y23mr22388998edt.190.1615212548919; Mon, 08 Mar 2021 06:09:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615212548; cv=none; d=google.com; s=arc-20160816; b=ynEJwMpn9elGCQcIYD1TBWjftdebSU4AK5NkfZZqLv8OqjjsGFJjN2DJiu8iQ8s6OG Z6W4sVfZk2U5N+7LZGcB84WdctTuKm18wPH33HcVb6OalXayrYp8r0p1Hi6TRIt003yA 5IP1HNmextiv9u/4mBODQJzSb8Kb9sLdeQ94aHgX2l3jKWA/W/4xJUw9TYQTd8JGLki9 UHKDk0b2FuEhVDB7V9y4zE/6VWlWKhohm0tDXn784C1iUEbtvXu8gvFd1xrqP00nxIdv chDP1/RhLY7c692sCEIre1whgdVyFdh4vvK/CBMSsdSzsThc2lpAcOKE/IHPI4jhIKRT EkwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=khcEQM92ONu5Eh1ZcQu9XwArmt7zKQYEB34c9J0wzTY=; b=uaxtqSesoK1L0OvFnyPiSIkUgY6YyqTZvTYHjsivSlsjtVW3NWrN7BEbprtMlm+dJP pTAnoUi3TiKeYPZCDPSFbeQ7TZPx9LO5Do/a5td25PUCtZMsX0gZ93HbdTdxo42PbKVE gqlTHoSUQoaRzZSjuXP0YI/UiTndXAs6UP8igQum2BlaE6LJKY8lam2yxHfrUfspLoqd xOS0w87JPo3jazgaLV+Irp+LiK0XiQisur8pq1NaXxbbWe3W/n1uXZpBvWk4cJxmstAR HSCWsKFhoyMbaY3rg8uMhb9QZ7kOk6xO/raukwley8bHiYtnGlqGKkwWmGSxkXaRqdJH YJGQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cc7si7214975edb.462.2021.03.08.06.08.46; Mon, 08 Mar 2021 06:09:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230410AbhCHOFW (ORCPT + 99 others); Mon, 8 Mar 2021 09:05:22 -0500 Received: from mx2.suse.de ([195.135.220.15]:33926 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229580AbhCHOEy (ORCPT ); Mon, 8 Mar 2021 09:04:54 -0500 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> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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