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 33A39C433DB for ; Wed, 17 Feb 2021 13:50:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C21C664D73 for ; Wed, 17 Feb 2021 13:50:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C21C664D73 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 3E53F6B0006; Wed, 17 Feb 2021 08:50:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 39BF56B006C; Wed, 17 Feb 2021 08:50:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25CF76B006E; Wed, 17 Feb 2021 08:50:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 0EAE86B0006 for ; Wed, 17 Feb 2021 08:50:31 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A8388180445FA for ; Wed, 17 Feb 2021 13:50:30 +0000 (UTC) X-FDA: 77827894620.18.E7BDA4C Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf28.hostedemail.com (Postfix) with ESMTP id C25132000D8E for ; Wed, 17 Feb 2021 13:50: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=1613569828; 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=LJwaVsNSdE6pGCu42lC4Cr77EcHivp6g9WAAtymIv4g=; b=s6GwlmutP0OO1buPuwUcMPcNUBshhtdznCjLE2fl6CjSgq2EADJM6PWgLhIXF0pSKvGqxU nvPilNP17O3xu7/0/R+bs2j56CNYJv+FU8lYwYKYP9LmVXT/XzI+SkEmgZYAHZnoCAal3n qhZPgs5jRhW0bfMqyfbR7OmkJb3JH94= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id CE58EB761; Wed, 17 Feb 2021 13:50:28 +0000 (UTC) Date: Wed, 17 Feb 2021 14:50:26 +0100 From: Michal Hocko To: David Hildenbrand Cc: Oscar Salvador , Andrew Morton , Mike Kravetz , Muchun Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] mm: Make alloc_contig_range handle free hugetlb pages Message-ID: References: <20210217100816.28860-1-osalvador@suse.de> <20210217100816.28860-2-osalvador@suse.de> <182f6a4a-6f95-9911-7730-8718ab72ece2@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <182f6a4a-6f95-9911-7730-8718ab72ece2@redhat.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C25132000D8E X-Stat-Signature: okway6roepjdsqwz3pu34diodwdjdi4x Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613569829-664981 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 Wed 17-02-21 14:36:47, David Hildenbrand wrote: > On 17.02.21 14:30, Michal Hocko wrote: > > On Wed 17-02-21 11:08:15, Oscar Salvador wrote: > > > Free hugetlb pages are tricky to handle so as to no userspace application > > > notices disruption, we need to replace the current free hugepage with > > > a new one. > > > > > > In order to do that, a new function called alloc_and_dissolve_huge_page > > > is introduced. > > > This function will first try to get a new fresh hugetlb page, and if it > > > succeeds, it will dissolve the old one. > > > > > > With regard to the allocation, since we do not know whether the old page > > > was allocated on a specific node on request, the node the old page belongs > > > to will be tried first, and then we will fallback to all nodes containing > > > memory (N_MEMORY). > > > > I do not think fallback to a different zone is ok. If yes then this > > really requires a very good reasoning. alloc_contig_range is an > > optimistic allocation interface at best and it shouldn't break carefully > > node aware preallocation done by administrator. > > What does memory offlining do when migrating in-use hugetlbfs pages? Does it > always keep the node? No it will break the node pool. The reasoning behind that is that offlining is an explicit request from the userspace and it is expected to break affinities because it is a destructive action from the memory capacity point of view. It is impossible to have former affinity while you are cutting the memory off under its user. > I think keeping the node is the easiest/simplest approach for now. > > > > > > Note that gigantic hugetlb pages are fenced off since there is a cyclic > > > dependency between them and alloc_contig_range. > > > > Why do we need/want to do all this in the first place? > > cma and virtio-mem (especially on ZONE_MOVABLE) really want to handle > hugetlbfs pages. Do we have any real life examples? Or does this fall more into, let's optimize an existing implementation category. -- Michal Hocko SUSE Labs