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=-7.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 DCE73C433DB for ; Wed, 17 Feb 2021 13:36:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7A9BE64E45 for ; Wed, 17 Feb 2021 13:36:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7A9BE64E45 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B5C1D6B006C; Wed, 17 Feb 2021 08:36:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B32C88D0002; Wed, 17 Feb 2021 08:36:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A728F8D0001; Wed, 17 Feb 2021 08:36:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 90F486B006C for ; Wed, 17 Feb 2021 08:36:57 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 58B98180AD83E for ; Wed, 17 Feb 2021 13:36:57 +0000 (UTC) X-FDA: 77827860474.05.bird44_0a0b62c2764c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 3CCF118038160 for ; Wed, 17 Feb 2021 13:36:57 +0000 (UTC) X-HE-Tag: bird44_0a0b62c2764c X-Filterd-Recvd-Size: 3996 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Wed, 17 Feb 2021 13:36:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613569016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CsqsRzQuTI8SkrwnCgergr3XDM20I5ZCGaVDpJ6qkLQ=; b=HCy0+7Yie6lHnhRa/V5oiyzx/84dBRPlQM+RXUJurCKeIM6TkWeeVkm50tYA8LWRh0VEUN gxdcqjordR2MqC/8bePxDn5meSH8TwNzQykSydHDYEFuVsmCOoAHcGQEuosqdEgMx/iDvi 1zx63IBg9J4fVJei7aCRIaaX8syyl34= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-573-ir5Es5WXMeivnoXWKTPXaQ-1; Wed, 17 Feb 2021 08:36:52 -0500 X-MC-Unique: ir5Es5WXMeivnoXWKTPXaQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 577F980196C; Wed, 17 Feb 2021 13:36:50 +0000 (UTC) Received: from [10.36.114.178] (ovpn-114-178.ams2.redhat.com [10.36.114.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id 539DD5C255; Wed, 17 Feb 2021 13:36:48 +0000 (UTC) Subject: Re: [PATCH 1/2] mm: Make alloc_contig_range handle free hugetlb pages To: Michal Hocko , Oscar Salvador Cc: Andrew Morton , Mike Kravetz , Muchun Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20210217100816.28860-1-osalvador@suse.de> <20210217100816.28860-2-osalvador@suse.de> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <182f6a4a-6f95-9911-7730-8718ab72ece2@redhat.com> Date: Wed, 17 Feb 2021 14:36:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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 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? 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. -- Thanks, David / dhildenb