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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 AA2C3C5519F for ; Sat, 14 Nov 2020 03:41:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 082AA22268 for ; Sat, 14 Nov 2020 03:40:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 082AA22268 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 20BC66B005C; Fri, 13 Nov 2020 22:40:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BE256B005D; Fri, 13 Nov 2020 22:40:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0ABA36B0068; Fri, 13 Nov 2020 22:40:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id D2D596B005C for ; Fri, 13 Nov 2020 22:40:54 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 757928249980 for ; Sat, 14 Nov 2020 03:40:54 +0000 (UTC) X-FDA: 77481622428.15.cord12_4403bc627314 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 501A31814B0C7 for ; Sat, 14 Nov 2020 03:40:54 +0000 (UTC) X-HE-Tag: cord12_4403bc627314 X-Filterd-Recvd-Size: 4067 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Sat, 14 Nov 2020 03:40:53 +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 1kdmQa-0001Ct-TF; Fri, 13 Nov 2020 22:40:40 -0500 Message-ID: <05f80e300fd4907b99837b5973db8985b7312d3f.camel@surriel.com> Subject: Re: [PATCH 2/2] mm,thp,shm: limit gfp mask to no more than specified From: Rik van Riel To: Michal Hocko 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, Andrey Grodzovsky , Chris Wilson Date: Fri, 13 Nov 2020 22:40:40 -0500 In-Reply-To: <20201112112242.GA12240@dhcp22.suse.cz> References: <20201105191508.1961686-1-riel@surriel.com> <20201105191508.1961686-3-riel@surriel.com> <20201112112242.GA12240@dhcp22.suse.cz> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-7F+/Ry5KAuETO7mOz6Ly" 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: --=-7F+/Ry5KAuETO7mOz6Ly Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2020-11-12 at 12:22 +0100, Michal Hocko wrote: > [Cc Chris for i915 and Andray] >=20 > On Thu 05-11-20 14:15:08, Rik van Riel wrote: > > 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 > It would be good to explicitly mention the requested gfp flags for > those > allocations. i915 uses __GFP_NORETRY | __GFP_NOWARN, or GFP_KERNEL. > Is > __shmem_rw really meant to not allocate from highmeme/movable zones? > Can > it be ever backed by THPs? You are right, I need to copy the zone flags __GFP_DMA through __GFP_MOVABLE straight from the limiting gfp_mask into the gfp_mask used for THP allocations, and not use the default THP zone flags if the caller specifies something else. I'll send out a new version that fixes that. > ttm might want __GFP_RETRY_MAYFAIL while shmem_read_mapping_page use > the mapping gfp mask which can be NOFS or something else. This is > quite > messy already and I suspect that they are more targeting regular > order-0 > requests. E.g. have a look at cb5f1a52caf23. >=20 > I am worried that this games with gfp flags will lead to > unmaintainable > code later on. There is a clear disconnect betwen the core THP > allocation strategy and what drivers are asking for and those > requirements might be really conflicting. Not to mention that flags > might be different between regular and THP pages. That is exactly why I want to make sure the THP allocations are never more aggressive than the gfp flags the drivers request, and the THP allocations may only ever be less aggressive than the order 0 gfp_mask specified by the drivers. --=20 All Rights Reversed. --=-7F+/Ry5KAuETO7mOz6Ly 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+vUbgACgkQznnekoTE 3oOgAwgAnHvtaJsxMpPNHFkPcrZjE8Zp6LrUY1qDU9vffSUstHg6juSUyEmmPUcy EsKzmfsV7QJz8kdMvBZW0MzrjJOQHNqlYTY3F9pv2ndFKy6WZe7WiCzXhH/VTHdk YDuDdNHJEjmL6kP/gaJMtYStbWxYv2fsxpGF0tq22Qn0FCAiLdLOXZD0699lOmxm kdMdYb0hJ8Gxj1YP6nW9bqb4KIH0MPFkxUgqb+B/DVxq63VA6mv+Iumzq705IhGW ymNXaBGXT8ZT8cgVbVQ5mzQcZolASKdmjE6pMJh5Y55LPo+54gUUubYC1j6TGrIk UCdzdX1+pAGEnCvbdgf/3m14JkNNvg== =KN5R -----END PGP SIGNATURE----- --=-7F+/Ry5KAuETO7mOz6Ly--