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 EF714C56202 for ; Thu, 26 Nov 2020 18:04:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 64AB1207BC for ; Thu, 26 Nov 2020 18:04:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64AB1207BC 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 F0EE86B0072; Thu, 26 Nov 2020 13:04:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EE4D76B0073; Thu, 26 Nov 2020 13:04:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD3DE6B0075; Thu, 26 Nov 2020 13:04:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id BDDAC6B0072 for ; Thu, 26 Nov 2020 13:04:24 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7EB3F363C for ; Thu, 26 Nov 2020 18:04:24 +0000 (UTC) X-FDA: 77527344048.15.juice75_4d0be9727381 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 5BD3F1814B0C8 for ; Thu, 26 Nov 2020 18:04:24 +0000 (UTC) X-HE-Tag: juice75_4d0be9727381 X-Filterd-Recvd-Size: 3554 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Thu, 26 Nov 2020 18:04:23 +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 1kiLcu-0003WL-9h; Thu, 26 Nov 2020 13:04:16 -0500 Message-ID: <920c627330f3c7d295ab58edd1b62f28fdbd14bc.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: Thu, 26 Nov 2020 13:04:14 -0500 In-Reply-To: <20201126134034.GI31550@dhcp22.suse.cz> References: <20201124194925.623931-1-riel@surriel.com> <20201124194925.623931-3-riel@surriel.com> <20201126134034.GI31550@dhcp22.suse.cz> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-67VJL8SKwNL83SFfDlDI" 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: --=-67VJL8SKwNL83SFfDlDI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2020-11-26 at 14:40 +0100, Michal Hocko wrote: > On Tue 24-11-20 14:49:24, 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 > > Make sure the gfp mask used to opportunistically allocate a THP > > is always at least as restrictive as the original gfp mask. >=20 > I have brought this up in the previous version review and I feel my > feedback hasn't been addressed. Please describe the expected behavior > by > those shmem users including GFP_KERNEL restriction which would make > the > THP flags incompatible. Is this a problem? Is there any actual > problem > if the THP uses its own set of flags? In the case of i915, the gfp flags passed in by the i915 driver expect the VM to easily fail the allocation, in which case the i915 driver will reclaim some existing buffers and try again. Trying harder than the original gfp_mask would change the OOM behavior of systems using the i915 driver. > I am also not happy how those two sets of flags are completely > detached > and we can only expect surprises there.=20 I would be more than happy to implement things differently, but I am not sure what alternative you are suggesting. --=20 All Rights Reversed. --=-67VJL8SKwNL83SFfDlDI 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+/7h4ACgkQznnekoTE 3oNYDwgAgSEz682PGBHWXeILtW9myPB2wDN8OOoSivRAGnVaJpQNflUsNke/pHMK ONtKDDwMRqE11vzjbqZUYPFfpYeDLyizno01z2j0NzrqU4pKBBYUZb32q6Nd39eU nZfpUtSxVWTS/r/GiC7BVwqJF/SkVQ8io8nlWZX2Thku6jdbo28spalaDw2hqIRV 978iyF1ljYpA20x6tZyZK5krhBecGqDHW4HDpuoo/ut8lj0IcXWQ3nFfzDLSkYIY hfU/Ltl3+59OYya4ghvJ9BlpiLHTon/2lPEDdbQrrjzcxai663iuwzuNwA00S4PY xrgK853amtt+fS4wx1brw3JZyWJXnA== =Eoqq -----END PGP SIGNATURE----- --=-67VJL8SKwNL83SFfDlDI--