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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 E0D17C433DB for ; Thu, 7 Jan 2021 03:57:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 891DE206F6 for ; Thu, 7 Jan 2021 03:57:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 891DE206F6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EE7446B02B3; Wed, 6 Jan 2021 22:57:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E97ED6B02B6; Wed, 6 Jan 2021 22:57:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD5036B02B9; Wed, 6 Jan 2021 22:57:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id C797D6B02B3 for ; Wed, 6 Jan 2021 22:57:24 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 911DF181AEF32 for ; Thu, 7 Jan 2021 03:57:24 +0000 (UTC) X-FDA: 77677619208.01.joke10_120370b274e7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 6B7541004E708 for ; Thu, 7 Jan 2021 03:57:24 +0000 (UTC) X-HE-Tag: joke10_120370b274e7 X-Filterd-Recvd-Size: 5611 Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Jan 2021 03:57:23 +0000 (UTC) Received: by mail-lf1-f45.google.com with SMTP id l11so11632848lfg.0 for ; Wed, 06 Jan 2021 19:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w+mL5mz+44KVkcz4bbzbq47jBM8tSe3hNfNBeoGgiNw=; b=Ckx4+8H705gHnCqZ2z7zk9akrGczZLyqw3IlP0ywLHbzHT1DE2Aq6Ck5bL0yoIAInV 16zM5VM0tyV0+9FVcKQ9EjMWAZEbd55d7xG29arO0BpB3jYEVD78+ppVqdEOlshvXI4b ld7QKCQAWtI8bYVBqFLpCDcjrm5vTJ81EI/4f7r5OZTGIjYjF6VCTG9NneDa3iUiLpkG pLnGz1w4W+Co4Z9OQxb1tBF6OS+C8ic8/+PFF7edkOlH8aWmEe/ksgez+9eicS3UmxnB 6vE2Gn1fnXk/7nlG3r7kM1UgTaa9kwqt9p93XpSKEVg93zLfPTBZkDLkj3mp8VD/EKwj CjIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w+mL5mz+44KVkcz4bbzbq47jBM8tSe3hNfNBeoGgiNw=; b=qeqJb7M/YW5doJNIqYDGYiDGICIwm8SrckwiZghcUs9wZ/tGby2e2uDr5dD/Ouwap/ 1e/80kpKj2Am5EyfMoPYnyCu8amozc8s/0rZFXOFPCaCztBhqUv4n/kstvOHMsyepBMF WMOWwcD/JMC3E+5H7FrcPj4CgNetGW5VDux5VtTyaAPbWxMVaZ/V5pJ8K/RWRXNEDqkG BBRYIa1kMDLt7Pt42QshrxuzjZLCa0/psI3MroPTun057Yjcq2ifdtUdIRgHyhqaYBdQ oq80LUR2R8EEtRWOovsfl5S79IUrs4nRzSL1NkUoo0+FRYZM0Kiag/4tM4vqShh+U0f1 HrGQ== X-Gm-Message-State: AOAM5307g/M30Gw8B2MQ054qQnJjZyOuwK8L0p1oLx8VWlNOeOgVOkCa l1p7muVW5l5q07cAzxfRLAJYvnoRx4Pm51SZmX0= X-Google-Smtp-Source: ABdhPJzch6I1tqMYg1Q5NOqSRoqhWuWDM8Ksmafh7GIivUfy9etpByNfzg88HMg/aQ7LX+/RBRsui/GczP8JtyCeJyA= X-Received: by 2002:a19:83c9:: with SMTP id f192mr2976342lfd.399.1609991842495; Wed, 06 Jan 2021 19:57:22 -0800 (PST) MIME-Version: 1.0 References: <20210106035027.GA1160@open-light-1.localdomain> In-Reply-To: From: Liang Li Date: Thu, 7 Jan 2021 11:57:09 +0800 Message-ID: Subject: Re: [PATCH 4/6] hugetlb: avoid allocation failed when page reporting is on going To: Alexander Duyck Cc: Mel Gorman , Andrew Morton , Andrea Arcangeli , Dan Williams , "Michael S. Tsirkin" , David Hildenbrand , Jason Wang , Dave Hansen , Michal Hocko , Liang Li , Mike Kravetz , linux-mm , LKML , virtualization@lists.linux-foundation.org Content-Type: text/plain; charset="UTF-8" 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: > > Page reporting isolates free pages temporarily when reporting > > free pages information. It will reduce the actual free pages > > and may cause application failed for no enough available memory. > > This patch try to solve this issue, when there is no free page > > and page repoting is on going, wait until it is done. > > > > Cc: Alexander Duyck > > Please don't use this email address for me anymore. Either use > alexander.duyck@gmail.com or alexanderduyck@fb.com. I am getting > bounces when I reply to this thread because of the old address. No problem. > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index eb533995cb49..0fccd5f96954 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -2320,6 +2320,12 @@ struct page *alloc_huge_page(struct vm_area_struct *vma, > > goto out_uncharge_cgroup_reservation; > > > > spin_lock(&hugetlb_lock); > > + while (h->free_huge_pages <= 1 && h->isolated_huge_pages) { > > + spin_unlock(&hugetlb_lock); > > + mutex_lock(&h->mtx_prezero); > > + mutex_unlock(&h->mtx_prezero); > > + spin_lock(&hugetlb_lock); > > + } > > This seems like a bad idea. It kind of defeats the whole point of > doing the page zeroing outside of the hugetlb_lock. Also it is > operating on the assumption that the only way you might get a page is > from the page zeroing logic. > > With the page reporting code we wouldn't drop the count to zero. We > had checks that were going through and monitoring the watermarks and > if we started to hit the low watermark we would stop page reporting > and just assume there aren't enough pages to report. You might need to > look at doing something similar here so that you can avoid colliding > with the allocator. For hugetlb, things are a little different, Just like Mike points out: "On some systems, hugetlb pages are a precious resource and the sysadmin carefully configures the number needed by applications. Removing a hugetlb page (even for a very short period of time) could cause serious application failure." Just keeping some pages in the freelist is not enough to prevent that from happening, because these pages may be allocated while zero out is on going, and application may still run into a situation for not available free pages. Thanks Liang