Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5764016pxu; Thu, 22 Oct 2020 10:23:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxL46rhIsaA/AsGexYPEFwWjJyCQSh6kHLWfuNVRlwkvfapFr1ZqX2jznIpijuJAjRTjXvp X-Received: by 2002:a05:6402:2292:: with SMTP id cw18mr3358697edb.112.1603387435106; Thu, 22 Oct 2020 10:23:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603387435; cv=none; d=google.com; s=arc-20160816; b=L2ZYko3Hp9sJS+PbDtKpXJ92htKYZZARmr96TsXFfaJTj++PCdcmwb7eBihoorE8mR q35kKbJbKdvGKb7myFhbazfxXw3q25bvyH+5m6IxLjsxpDdmyonsnQhZn0CA5tCjhbLH Svb0gdAVGoqigBHZwjBI7yTYl1La/R8SHewqHCFM5Eqdth4PrFEd5YLmbGpklbqKQGJG HPdCh7qzDkwnvGXtqTKyPgwl6Pk9DDBeXAD60+KZqCa72PQaR0OJrEF2zS0T6g0G1q24 VOwuhNcOJDRd4Lhs73Y2BqX/YW7GGZS1ucZF1WWjZlkDW688ZQ0PyvQPU6M/X98aHFLu ZWUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id; bh=ebM7/j2kX/W7CeibLBDSduLbcNQ53rXuMTAocTZJSCE=; b=YD2IPsp0x5mABQ6gzwko1zPj1cKk/gllDHKcy2f5LW7LYoBCH1VZfb2AvLSlVAoJW8 +PJf4DwKnPMhKfnyUacCngcVdTctbVtgdOS+9Vbq8c39RKsiuJXus1zN4jSylg6wX0U8 1SFfpNrmTcd8qxC8I/6VVIzDgOg5AeiFrZRkrk+PddgFvFCQZ8mu88KVmi08Rmz5EGO5 XD1k/wYhS3ErpW3ZJnVb1E979b2f7FL+rQUIRwiGGz+Alz11lIdg5VWFgdm4thVvTC5r QrQch8lVlBhCWy+o4WgpFCNTffP2buQ5UYgxM7lqVf0J9ZxyDVNlpLnWhGwNaBkXpfB7 O4sQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ga26si1177365ejc.292.2020.10.22.10.23.32; Thu, 22 Oct 2020 10:23:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2894889AbgJVNZ2 (ORCPT + 99 others); Thu, 22 Oct 2020 09:25:28 -0400 Received: from shelob.surriel.com ([96.67.55.147]:34480 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2507061AbgJVNZ2 (ORCPT ); Thu, 22 Oct 2020 09:25:28 -0400 Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kVaan-0007zP-Jb; Thu, 22 Oct 2020 09:25:21 -0400 Message-ID: <004062456494e9003b0f71b911f06f8c58a12797.camel@surriel.com> Subject: Re: [PATCH] mm,thp,shmem: limit shmem THP alloc gfp_mask From: Rik van Riel To: Michal Hocko Cc: Hugh Dickins , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Mel Gorman , Andrea Arcangeli , Matthew Wilcox Date: Thu, 22 Oct 2020 09:25:21 -0400 In-Reply-To: <20201022081532.GJ23790@dhcp22.suse.cz> References: <20201021234846.5cc97e62@imladris.surriel.com> <20201022081532.GJ23790@dhcp22.suse.cz> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-S6o55Dk7sGpm11/Uyo3G" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Sender: riel@shelob.surriel.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-S6o55Dk7sGpm11/Uyo3G Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2020-10-22 at 10:15 +0200, Michal Hocko wrote: > On Wed 21-10-20 23:48:46, Rik van Riel wrote: > > The allocation flags of anonymous transparent huge pages can be > > controlled > > through the files in /sys/kernel/mm/transparent_hugepage/defrag, > > which can > > help the system from getting bogged down in the page reclaim and > > compaction > > code when many THPs are getting allocated simultaneously. > >=20 > > However, the gfp_mask for shmem THP allocations were not limited by > > those > > configuration settings, and some workloads ended up with all CPUs > > stuck > > on the LRU lock in the page reclaim code, trying to allocate dozens > > of > > THPs simultaneously. > >=20 > > This patch applies the same configurated limitation of THPs to > > shmem > > hugepage allocations, to prevent that from happening. > >=20 > > This way a THP defrag setting of "never" or "defer+madvise" will > > result > > in quick allocation failures without direct reclaim when no 2MB > > free > > pages are available. >=20 > I remmeber I wanted to unify this in the past as well. The patch got > reverted in the end. It was a long story and I do not have time to > read > through lengthy discussions again. I do remember though that there > were > some objections pointing out that shmem has its own behavior which is > controlled by the mount option - at least for the explicitly mounted > shmems. I might misremember. That is not entirely true, though. THP has two main sysfs knobs: "enabled" and "defrag" The mount options control the shmem equivalent options for "enabled", but they do not do anything for the "defrag" equivalent options. This patch applies the "defrag" THP options to shmem. > [...] >=20 > > diff --git a/mm/shmem.c b/mm/shmem.c > > index 537c137698f8..d1290eb508e5 100644 > > --- a/mm/shmem.c > > +++ b/mm/shmem.c > > @@ -1545,8 +1545,11 @@ static struct page > > *shmem_alloc_hugepage(gfp_t gfp, > > return NULL; > > =20 > > shmem_pseudo_vma_init(&pvma, info, hindex); > > - page =3D alloc_pages_vma(gfp | __GFP_COMP | __GFP_NORETRY | > > __GFP_NOWARN, > > - HPAGE_PMD_ORDER, &pvma, 0, numa_node_id(), > > true); > > + /* Limit the gfp mask according to THP configuration. */ > > + gfp |=3D __GFP_COMP | __GFP_NORETRY | __GFP_NOWARN; >=20 > What is the reason for these when alloc_hugepage_direct_gfpmask > provides > the full mask? The mapping_gfp_mask for the shmem file might have additional restrictions above and beyond the gfp mask returned by alloc_hugepage_direct_gfpmask, and I am not sure we should just ignore the mapping_gfp_mask. That is why this patch takes the union of both gfp masks. However, digging into things more, it looks like shmem inodes always have the mapping gfp mask set to GFP_HIGHUSER_MOVABLE, and it is never changed, so simply using the output from alloc_hugepage_direct_gfpmask should be fine. I can do the patch either way. Just let me know what you prefer. > > + gfp &=3D alloc_hugepage_direct_gfpmask(&pvma); > > + page =3D alloc_pages_vma(gfp, HPAGE_PMD_ORDER, &pvma, 0, > > numa_node_id(), > > + true); > > shmem_pseudo_vma_destroy(&pvma); > > if (page) > > prep_transhuge_page(page); > >=20 > > --=20 > > All rights reversed. --=20 All Rights Reversed. --=-S6o55Dk7sGpm11/Uyo3G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAl+RiEEACgkQznnekoTE 3oNyPQf8DJWaHRulqI0zU7h6A5fMQC9csTAy5hwygvjAL5MDI3WbuVIqhOYxJJmZ 8m89mr7foiLfsSiyAGXvF3cQ1ysyxjp4ddg/YJFmSS2aQ4j7DQ+pu5mr/CQFvcje fRmNgXKnh4LJkRW6wX/5RX7U13xNL3Qi0C5K5Vg1Nn0pr9ujq6Aq5qPoyICtYl3K ENbI6QZMdXZPglqwB/cUxIsFtqOr9WLfPls0ytHm6dspB7JGzQyXRiYi5G8afzmz 6qhBECGY9EPQWZ6kOJwb0efKz+FlhI6owJ7S4oeCyv4pt4byihxEbfVqC2+4BrVm p3V23yuYKliuaOXexp5PhhWgMjQwaw== =IxrV -----END PGP SIGNATURE----- --=-S6o55Dk7sGpm11/Uyo3G--