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=-8.0 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=ham 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 AAD70C433E0 for ; Wed, 10 Feb 2021 14:36:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 29775614A5 for ; Wed, 10 Feb 2021 14:36:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29775614A5 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 9E10C6B0070; Wed, 10 Feb 2021 09:36:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 991596B0071; Wed, 10 Feb 2021 09:36:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87FE96B0072; Wed, 10 Feb 2021 09:36:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id 7069D6B0070 for ; Wed, 10 Feb 2021 09:36:49 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3D13B12609 for ; Wed, 10 Feb 2021 14:36:49 +0000 (UTC) X-FDA: 77802609738.14.0260426 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 371DA80191F1 for ; Wed, 10 Feb 2021 14:36:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612967808; 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=y0cOXkjjqhYfEYLaqUjm8JsPqdbJg8o77yvHL5dd1FI=; b=M9nHWKcgHqXZl0NVce0SkiwgsSFKUMav2JhCkAa0/TDQakgoC2QFo3nCoUV3UM+1JdZ/Bl tYSSw1/OTjz0UkcKPlBt9x+0krNNS2slUhzvF7GyNSJ/VgFPsNaA5ffos1IME5y9mvmrDc MhHmYKE8ZWdAMBbzF30x7nFuxWrFzIQ= 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-29-n8rUQhb7MnOwA1wTH2RqWA-1; Wed, 10 Feb 2021 09:36:45 -0500 X-MC-Unique: n8rUQhb7MnOwA1wTH2RqWA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2C36780196E; Wed, 10 Feb 2021 14:36:44 +0000 (UTC) Received: from [10.36.113.218] (ovpn-113-218.ams2.redhat.com [10.36.113.218]) by smtp.corp.redhat.com (Postfix) with ESMTP id C6DE918AA1; Wed, 10 Feb 2021 14:36:42 +0000 (UTC) Subject: Re: [RFC PATCH 2/2] mm,page_alloc: Make alloc_contig_range handle free hugetlb pages To: Oscar Salvador Cc: Mike Kravetz , Muchun Song , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20210208103812.32056-1-osalvador@suse.de> <20210208103812.32056-3-osalvador@suse.de> <9ed946df-9c6c-9a4d-4be9-2f32809974f7@redhat.com> <20210210142424.GC3636@localhost.localdomain> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <6e999708-2edb-c25f-4aee-217d2f3cc037@redhat.com> Date: Wed, 10 Feb 2021 15:36:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20210210142424.GC3636@localhost.localdomain> 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.11 X-Stat-Signature: k9a67xps937q783kfdofpukncatm58uf X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 371DA80191F1 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1612967808-516386 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 10.02.21 15:24, Oscar Salvador wrote: > On Wed, Feb 10, 2021 at 09:23:59AM +0100, David Hildenbrand wrote: >> On 08.02.21 11:38, Oscar Salvador wrote: >>> Free hugetlb pages are trickier to handle as to in order to guarantee >>> no userspace appplication 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 >>> in introduced. >>> This function will first try to get a new fresh hugetlb page, and if it >>> succeeds, it will dissolve the old one. >>> >> >> Thanks for looking into this! Can we move this patch to #1 in the series? It >> is the easier case. >> >> I also wonder if we should at least try on the memory unplug path to keep >> nr_pages by at least trying to allocate at new one if required, and printing >> a warning if that fails (after all, we're messing with something configured >> by the admin - "nr_pages"). Note that gigantic pages are special (below). > > So, do you mean to allocate a new fresh hugepage in case we have a free > hugetlb page within the range we are trying to offline? That makes some > sense I guess. > > I can have a look at that, and make hotplug code use the new > alloc_and_dissolve(). Yes, with the difference that hotplug code most probably wants to continue even if allocation failed (printing a warning) - mimix existing behavior. For alloc_contig, I'd say, fail if we cannot "relocate free huge pages that are still required to no modify nr_pages". alloc_and_dissolve() should only allocate a page if really required (e.g., not sure if we could skip allocation in some cases - like with surplus pages, needs some investigation), such that the admin-configured nr_pages stays unchanged. -- Thanks, David / dhildenb