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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 A6A04C433DB for ; Tue, 12 Jan 2021 11:27:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3DE4D23104 for ; Tue, 12 Jan 2021 11:27:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3DE4D23104 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 B776D8D009B; Tue, 12 Jan 2021 06:27:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B279B8D0090; Tue, 12 Jan 2021 06:27:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3DEA8D009B; Tue, 12 Jan 2021 06:27:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 8E64F8D0090 for ; Tue, 12 Jan 2021 06:27:12 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 44938362B for ; Tue, 12 Jan 2021 11:27:12 +0000 (UTC) X-FDA: 77696896704.25.scale23_2c113b227515 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 241F81804E3A1 for ; Tue, 12 Jan 2021 11:27:12 +0000 (UTC) X-HE-Tag: scale23_2c113b227515 X-Filterd-Recvd-Size: 4074 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 11:27:11 +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=1610450830; 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=fOyq5TGHjwaWM/gs+g8r/1umBTXa3AfXQnevS1L+Rz4=; b=CtoiggA4j3Fnbl3WxynfsLLp7i3hfeZcEAAULTFDzyuo6Wg6gDmuTIZDlIcP4JLVdjAUJU 7uE/MX0NmqEtSAP34fMEpRLW5wEzDmA7nMhyX7xPkfV3+EmmWyPYgFIicsS7rDcA/bKr/O Xv5czUBbAIKs2mjIBbz4GYSDx0QENX0= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 6ECCCAFAE; Tue, 12 Jan 2021 11:27:10 +0000 (UTC) Date: Tue, 12 Jan 2021 12:27:09 +0100 From: Michal Hocko To: David Hildenbrand Cc: Muchun Song , mike.kravetz@oracle.com, akpm@linux-foundation.org, n-horiguchi@ah.jp.nec.com, ak@linux.intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yang Shi Subject: Re: [PATCH v3 1/6] mm: migrate: do not migrate HugeTLB page whose refcount is one Message-ID: <20210112112709.GO22493@dhcp22.suse.cz> References: <20210110124017.86750-1-songmuchun@bytedance.com> <20210110124017.86750-2-songmuchun@bytedance.com> <1b39d654-0b8c-de3a-55d1-6ab8c2b2e0ba@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue 12-01-21 12:11:21, David Hildenbrand wrote: > On 12.01.21 12:00, David Hildenbrand wrote: > > On 10.01.21 13:40, Muchun Song wrote: > >> If the refcount is one when it is migrated, it means that the page > >> was freed from under us. So we are done and do not need to migrate. > >> > >> This optimization is consistent with the regular pages, just like > >> unmap_and_move() does. > >> > >> Signed-off-by: Muchun Song > >> Reviewed-by: Mike Kravetz > >> Acked-by: Yang Shi > >> --- > >> mm/migrate.c | 6 ++++++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/mm/migrate.c b/mm/migrate.c > >> index 4385f2fb5d18..a6631c4eb6a6 100644 > >> --- a/mm/migrate.c > >> +++ b/mm/migrate.c > >> @@ -1279,6 +1279,12 @@ static int unmap_and_move_huge_page(new_page_t get_new_page, > >> return -ENOSYS; > >> } > >> > >> + if (page_count(hpage) == 1) { > >> + /* page was freed from under us. So we are done. */ > >> + putback_active_hugepage(hpage); > >> + return MIGRATEPAGE_SUCCESS; > >> + } > >> + > >> new_hpage = get_new_page(hpage, private); > >> if (!new_hpage) > >> return -ENOMEM; > >> > > > > Question: What if called via alloc_contig_range() where we even want to > > "migrate" free pages, meaning, relocate it? > > > > To be more precise: > > a) We don't have dissolve_free_huge_pages() calls on the > alloc_contig_range() path. So we *need* migration IIUC. > > b) dissolve_free_huge_pages() will fail if going below the reservation. > In that case we really want to migrate free pages. This even applies to > memory offlining. > > Either I am missing something important or this patch is more dangerous > than it looks like. This is an interesting point. But do we try to migrate hugetlb pages in alloc_contig_range? isolate_migratepages_block !PageLRU need to be marked as PageMovable AFAICS. This would be quite easy to implement but a more fundamental question is whether we really want to mess with existing pools for alloc_contig_range. Anyway you are quite right that this change has more side effects than it is easy to see while it doesn't really bring any major advantage other than the code consistency. -- Michal Hocko SUSE Labs