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=-9.5 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 612ECC388F7 for ; Fri, 6 Nov 2020 03:05:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6F27B2080D for ; Fri, 6 Nov 2020 03:05:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F27B2080D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7576E6B005C; Thu, 5 Nov 2020 22:05:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 708F06B005D; Thu, 5 Nov 2020 22:05:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 645956B0068; Thu, 5 Nov 2020 22:05:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0113.hostedemail.com [216.40.44.113]) by kanga.kvack.org (Postfix) with ESMTP id 379606B005C for ; Thu, 5 Nov 2020 22:05:31 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D1F0F3629 for ; Fri, 6 Nov 2020 03:05:30 +0000 (UTC) X-FDA: 77452502820.08.bit47_2705fba272cf Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id B460F1819E76C for ; Fri, 6 Nov 2020 03:05:30 +0000 (UTC) X-HE-Tag: bit47_2705fba272cf X-Filterd-Recvd-Size: 3224 Received: from r3-17.sinamail.sina.com.cn (r3-17.sinamail.sina.com.cn [202.108.3.17]) by imf33.hostedemail.com (Postfix) with SMTP for ; Fri, 6 Nov 2020 03:05:26 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([103.193.190.174]) by sina.com with ESMTP id 5FA4BD70000049A9; Fri, 6 Nov 2020 11:05:23 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 55607649283579 From: Hillf Danton To: Rik van Riel Cc: hughd@google.com, xuyu@linux.alibaba.com, akpm@linux-foundation.org, mgorman@suse.de, aarcange@redhat.com, willy@infradead.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, linux-mm@kvack.org, vbabka@suse.cz, mhocko@suse.com Subject: Re: [PATCH 2/2] mm,thp,shm: limit gfp mask to no more than specified Date: Fri, 6 Nov 2020 11:05:11 +0800 Message-Id: <20201106030511.396-1-hdanton@sina.com> In-Reply-To: <20201105191508.1961686-3-riel@surriel.com> References: <20201105191508.1961686-1-riel@surriel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 Thu, 5 Nov 2020 14:15:08 -0500 >=20 > Matthew Wilcox pointed out that the i915 driver opportunistically > allocates tmpfs memory, but will happily reclaim some of its > pool if no memory is available. >=20 > Make sure the gfp mask used to opportunistically allocate a THP > is always at least as restrictive as the original gfp mask. >=20 > Signed-off-by: Rik van Riel > Suggested-by: Matthew Wilcox > --- > mm/shmem.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) >=20 > diff --git a/mm/shmem.c b/mm/shmem.c > index 6c3cb192a88d..ee3cea10c2a4 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -1531,6 +1531,26 @@ static struct page *shmem_swapin(swp_entry_t swa= p, gfp_t gfp, > return page; > } > =20 > +/* > + * Make sure huge_gfp is always more limited than limit_gfp. > + * Some of the flags set permissions, while others set limitations. > + */ > +static gfp_t limit_gfp_mask(gfp_t huge_gfp, gfp_t limit_gfp) > +{ > + gfp_t allowflags =3D __GFP_IO | __GFP_FS | __GFP_RECLAIM; > + gfp_t denyflags =3D __GFP_NOWARN | __GFP_NORETRY; > + gfp_t result =3D huge_gfp & ~allowflags; > + > + /* > + * Minimize the result gfp by taking the union with the deny flags, > + * and the intersection of the allow flags. > + */ > + result |=3D (limit_gfp & denyflags); Currently NORETRY is always set regardless of i915 and if it's determined in 1/2 then the i915 thing can be done like return huge_gfp | (limit_gfp & __GFP_RECLAIM); in assumption that 1/2 gives the baseline gfp shmem needs. > + result |=3D (huge_gfp & limit_gfp) & allowflags; > + > + return result; > +} > + > static struct page *shmem_alloc_hugepage(gfp_t gfp, > struct shmem_inode_info *info, pgoff_t index) > { > @@ -1889,6 +1909,7 @@ static int shmem_getpage_gfp(struct inode *inode,= pgoff_t index, > =20 > alloc_huge: > huge_gfp =3D vma_thp_gfp_mask(vma); > + huge_gfp =3D limit_gfp_mask(huge_gfp, gfp); > page =3D shmem_alloc_and_acct_page(huge_gfp, inode, index, true); > if (IS_ERR(page)) { > alloc_nohuge: > --=20 > 2.25.4