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=-6.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 7C289C388F7 for ; Thu, 22 Oct 2020 13:25:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 544DC222E9 for ; Thu, 22 Oct 2020 13:25:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 544DC222E9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BFD6F6B007E; Thu, 22 Oct 2020 09:25:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BACF96B0080; Thu, 22 Oct 2020 09:25:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC3F16B0081; Thu, 22 Oct 2020 09:25:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id 805686B007E for ; Thu, 22 Oct 2020 09:25:28 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2DF141EE6 for ; Thu, 22 Oct 2020 13:25:28 +0000 (UTC) X-FDA: 77399633136.09.fall20_541128b27251 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 0DDE6180AD817 for ; Thu, 22 Oct 2020 13:25:28 +0000 (UTC) X-HE-Tag: fall20_541128b27251 X-Filterd-Recvd-Size: 5534 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Thu, 22 Oct 2020 13:25:27 +0000 (UTC) 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 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: --=-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--