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.8 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 A60E0C433E0 for ; Thu, 7 Jan 2021 17:56:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3ECE5233FD for ; Thu, 7 Jan 2021 17:56:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3ECE5233FD 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 53ACD8D0140; Thu, 7 Jan 2021 12:56:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C4898D013A; Thu, 7 Jan 2021 12:56:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38BB48D0140; Thu, 7 Jan 2021 12:56:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0037.hostedemail.com [216.40.44.37]) by kanga.kvack.org (Postfix) with ESMTP id 1D3EC8D013A for ; Thu, 7 Jan 2021 12:56:31 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D7F37180AD807 for ; Thu, 7 Jan 2021 17:56:30 +0000 (UTC) X-FDA: 77679733740.19.face33_5017a4d274ec Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id AE4661ACEAD for ; Thu, 7 Jan 2021 17:56:30 +0000 (UTC) X-HE-Tag: face33_5017a4d274ec X-Filterd-Recvd-Size: 6662 Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Jan 2021 17:56:29 +0000 (UTC) Received: by mail-il1-f174.google.com with SMTP id t3so3457249ilh.9 for ; Thu, 07 Jan 2021 09:56:29 -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=gIcTJnmCObWJEcPsEVSzZEbUrwSNec8NhE63eBq7ZSM=; b=Q2YrzMgiAxkXvm9SqzdMmHt/P1Q3M9VnclkYPlj3KXvMS/VdYP3gLVH9iWfi/tPfJW 1ohVoytOusKvdsnudhL748xmMxKTx7YBk99jXoeatAdd9FHMFLFk5l7g/TM/KY5snEdF l0/qgeWJoRyUQi7Wty/0E0ufwlC4/2sLCis8IhzGwT2j7BZDIcWT6iHKVxizOccE+bDH 0BdkWOCmUK0CbbhAzv5C6fAenYzSxPe0C3EOIadGWdvl7ABNS/xyzeo8KoUZvz0EaVSK 5jry93pSQujT1YsqNOeVAY/9W0IB0TYiJtUYwE9AwMoa/JUCLLa7heo9RtcVDBm4m5kE mbeA== 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=gIcTJnmCObWJEcPsEVSzZEbUrwSNec8NhE63eBq7ZSM=; b=huaqidJjPRSgT2jNd1wInqbjTP6cFVuAc+Dr2XbyJQKYKc51tLC8iaar7ex2PWHXF/ 9YqECA0qJDKMJsPNtx2ppJjSh29TlU0SUOYeZtNYHczax8y+OmMvadWK5KvZy3zwHNb4 HWty9O8cR92fWZtXrGdlDEN1OFQav6rgqkbyBY9Em08N1euonoZ7050Q8pPbpqGrDLFX 2l+4Umnit18RlfAfZsNXfECpd+jcGI6OPpe5SBquEO91CH6+vsPyjWhajJx7sStFiXLY ekcmHCW3q7JgIxkDxx4VowudJzVDAh1yoBoYxSchJEyJt7Zl/uFGir8bSfY2KduJ51vE 8ebQ== X-Gm-Message-State: AOAM5330t5GVpAcsBrz3jWj6HfPGtwivMEobG+9F84HLRsfrSXDrl69D 4GDqgZkf7/tYXt0cOp/k5F0N8QUNmKI5nyKt+Y8= X-Google-Smtp-Source: ABdhPJzpGidOJI6I9ogzE3vbvyp2WNvFouko1ksIuIDvXVu11Iivfx97nwvbu3D+KbJDypKndB70eA+Nz4JBOgdYGZM= X-Received: by 2002:a92:d592:: with SMTP id a18mr57802iln.64.1610042189444; Thu, 07 Jan 2021 09:56:29 -0800 (PST) MIME-Version: 1.0 References: <20210106035027.GA1160@open-light-1.localdomain> In-Reply-To: From: Alexander Duyck Date: Thu, 7 Jan 2021 09:56:18 -0800 Message-ID: Subject: Re: [PATCH 4/6] hugetlb: avoid allocation failed when page reporting is on going To: Liang Li 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: On Wed, Jan 6, 2021 at 7:57 PM Liang Li wrote: > > > > 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. I get what you are saying. However I don't know if it is acceptable for the allocating thread to be put to sleep in this situation. There are two scenarios where I can see this being problematic. One is a setup where you put the page allocator to sleep and while it is sleeping another thread is then freeing a page and your thread cannot respond to that newly freed page and is stuck waiting on the zeroed page. The second issue is that users may want a different option of just breaking up the request into smaller pages rather than waiting on the page zeroing, or to do something else while waiting on the page. So instead of sitting on the request and waiting it might make more sense to return an error pointer like EAGAIN or EBUSY to indicate that there is a page there, but it is momentarily tied up.