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.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 DFBAFC433E0 for ; Wed, 24 Feb 2021 08:31:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5426E64DE0 for ; Wed, 24 Feb 2021 08:31:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5426E64DE0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B62706B0006; Wed, 24 Feb 2021 03:31:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AEC9E6B006C; Wed, 24 Feb 2021 03:31:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 964D76B0071; Wed, 24 Feb 2021 03:31:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 72F3D6B0006 for ; Wed, 24 Feb 2021 03:31:58 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 4162A8248D52 for ; Wed, 24 Feb 2021 08:31:58 +0000 (UTC) X-FDA: 77852493516.29.86D169E Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf12.hostedemail.com (Postfix) with ESMTP id E7F03DA for ; Wed, 24 Feb 2021 08:31:51 +0000 (UTC) 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 F39D9AF3E; Wed, 24 Feb 2021 08:31:55 +0000 (UTC) Date: Wed, 24 Feb 2021 09:31:49 +0100 From: Oscar Salvador To: Muchun Song Cc: Mike Kravetz , Jonathan Corbet , Thomas Gleixner , mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, Peter Zijlstra , viro@zeniv.linux.org.uk, Andrew Morton , paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, Randy Dunlap , oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, Mina Almasry , David Rientjes , Matthew Wilcox , Michal Hocko , "Song Bao Hua (Barry Song)" , David Hildenbrand , HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+jIOebtOS5nyk=?= , Joao Martins , Xiongchun duan , linux-doc@vger.kernel.org, LKML , Linux Memory Management List , linux-fsdevel Subject: Re: [External] Re: [PATCH v16 4/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page Message-ID: <20210224083145.GA14894@linux> References: <20210219104954.67390-1-songmuchun@bytedance.com> <20210219104954.67390-5-songmuchun@bytedance.com> <13a5363c-6af4-1e1f-9a18-972ca18278b5@oracle.com> <20210223092740.GA1998@linux> <20210223104957.GA3844@linux> <20210223154128.GA21082@localhost.localdomain> <20210223223157.GA2740@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Stat-Signature: oi17j3kgpjhg4ciiqs7ohq8z995peqyr X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E7F03DA Received-SPF: none (suse.de>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1614155511-428902 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, Feb 24, 2021 at 11:47:49AM +0800, Muchun Song wrote: > I have been looking at the dequeue_huge_page_node_exact(). > If a PageHWPoison huge page is in the free pool list, the page will > not be allocated to the user. The PageHWPoison huge page > will be skip in the dequeue_huge_page_node_exact(). Yes, now I see where the problem lies. hugetlb_no_page()->..->dequeue_huge_page_node_exact() will fail if the only page in the pool is hwpoisoned, as expected. Then alloc_buddy_huge_page_with_mpol() will be tried, but since surplus_huge_pages counter is stale, we will fail there. That relates to the problem Mike pointed out, that we should decrease again the surplus_huge_pages. I think hwpoisoned pages should not be in the free pool though. Probably we want to take them off when we notice we have one: e.g: dequeue_huge_page_node_exact could place the page in another list and place it back in case it was unpoisoned. But anyway, that has nothing to do with this (apart from the surplus problem). -- Oscar Salvador SUSE L3