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 B04BBC64E90 for ; Mon, 30 Nov 2020 14:40:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E7B4120731 for ; Mon, 30 Nov 2020 14:40:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E7B4120731 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 4C6598D0002; Mon, 30 Nov 2020 09:40:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 49F948D0001; Mon, 30 Nov 2020 09:40:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DA6C8D0002; Mon, 30 Nov 2020 09:40:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id 263638D0001 for ; Mon, 30 Nov 2020 09:40:15 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9C60D3635 for ; Mon, 30 Nov 2020 14:40:14 +0000 (UTC) X-FDA: 77541344748.10.cat38_5a13032273a2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 6672116A0DE for ; Mon, 30 Nov 2020 14:40:14 +0000 (UTC) X-HE-Tag: cat38_5a13032273a2 X-Filterd-Recvd-Size: 3851 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Mon, 30 Nov 2020 14:40:13 +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 1kjkLR-0000v7-Ii; Mon, 30 Nov 2020 09:40:01 -0500 Message-ID: <0bf4037559563bd51f6ac68d659e9f886387fa7e.camel@surriel.com> Subject: Re: [PATCH 2/3] 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 Date: Mon, 30 Nov 2020 09:40:01 -0500 In-Reply-To: <20201130100053.GD17338@dhcp22.suse.cz> References: <20201124194925.623931-1-riel@surriel.com> <20201124194925.623931-3-riel@surriel.com> <20201126134034.GI31550@dhcp22.suse.cz> <920c627330f3c7d295ab58edd1b62f28fdbd14bc.camel@surriel.com> <20201127075214.GK31550@dhcp22.suse.cz> <1f089a155d7501fb156da34744d282ae1f3d02f7.camel@surriel.com> <20201130100053.GD17338@dhcp22.suse.cz> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-MwKFZQvAu7UAtgs7ip0f" 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: --=-MwKFZQvAu7UAtgs7ip0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2020-11-30 at 11:00 +0100, Michal Hocko wrote: > On Fri 27-11-20 14:03:39, Rik van Riel wrote: > > On Fri, 2020-11-27 at 08:52 +0100, Michal Hocko wrote: > > > On Thu 26-11-20 13:04:14, Rik van Riel wrote: > > > > I would be more than happy to implement things differently, > > > > but I am not sure what alternative you are suggesting. > > >=20 > > > Simply do not alter gfp flags? Or warn in some cases of a serious > > > mismatch. > > > E.g. GFP_ZONEMASK mismatch because there are already GFP_KERNEL > > > users > > > of > > > shmem. > >=20 > > Not altering the gfp flags is not really an option, > > because that would leads to attempting to allocate THPs > > with GFP_HIGHUSER, which is what is used to allocate > > regular tmpfs pages. >=20 > Right but that is a completely different reason to alter the mask and > it > would be really great to know whether this is a theoretical concern > or > those users simply do not ever use THPs. Btw. should they be using > THPs > even if they opt themselves into GFP_KERNEL restriction? I suppose disabling THPs completely if the gfp_mask passed to shmem_getpage_gfp() is not GFP_HIGHUSER is another option. That seems like it might come with its own pitfalls, though, both functionality wise and maintenance wise. Does anyone have strong feelings between "limit gfp_mask" and "disable THP for !GFP_HIGHUSER"? --=20 All Rights Reversed. --=-MwKFZQvAu7UAtgs7ip0f 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/FBEEACgkQznnekoTE 3oMGOAf/cwgErDAEtBf5TbUyPbr3g7+END1IDIIyQm7IAI7NhbuuikStX+3cDdEp FJPP/hOHqEj3+X9j6wFwovpsnhac8C/iuCoif5QJ+5HyJbDGCcK7EKxubdTHZMD0 jyJG0U2M8XACDoXiImhfZ0P61mWeYAoOl7S+CLtAP/XcM067M2Jp+q5F+ARZRN94 2pr4z+A2xHoShqWdG/BX6pOX5O27yggZaQejLLU0uPulbitd8WP4X0zY2h4IyKtL jD2p25Wcax8mvZJhNM/0V00/diPwI8nm6SgJIG4eGg1FKB+KkUhY9jzh8icE7vuO LKi4pLDIHziGqlsa1Cm1MLXbVj5F2Q== =a55D -----END PGP SIGNATURE----- --=-MwKFZQvAu7UAtgs7ip0f--