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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 04172C2BB1D for ; Tue, 14 Apr 2020 03:56:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C246D2072D for ; Tue, 14 Apr 2020 03:56:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C246D2072D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4EBCE8E0003; Mon, 13 Apr 2020 23:56:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 49BED8E0001; Mon, 13 Apr 2020 23:56:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D7A08E0003; Mon, 13 Apr 2020 23:56:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 247038E0001 for ; Mon, 13 Apr 2020 23:56:36 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DADB6582B for ; Tue, 14 Apr 2020 03:56:35 +0000 (UTC) X-FDA: 76705098750.26.plant40_56a2e5f003530 X-HE-Tag: plant40_56a2e5f003530 X-Filterd-Recvd-Size: 5180 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 03:56:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A30A2ABB2; Tue, 14 Apr 2020 03:56:32 +0000 (UTC) From: NeilBrown To: Andrew Morton , John Hubbard Date: Tue, 14 Apr 2020 13:56:25 +1000 Cc: David Rientjes , Michal Hocko , Joel Fernandes , "Paul E. McKenney" , linux-mm@kvack.org, LKML Subject: Re: [PATCH 1/2] mm: clarify __GFP_MEMALLOC usage In-Reply-To: <20200413191532.6b234b50caea9134fb95a151@linux-foundation.org> References: <20200403083543.11552-1-mhocko@kernel.org> <20200403083543.11552-2-mhocko@kernel.org> <87blo8xnz2.fsf@notabene.neil.brown.name> <20200406070137.GC19426@dhcp22.suse.cz> <4f861f07-4b47-8ddc-f783-10201ea302d3@nvidia.com> <20200413191532.6b234b50caea9134fb95a151@linux-foundation.org> Message-ID: <87h7xmu3di.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" 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: --=-=-= Content-Type: text/plain On Mon, Apr 13 2020, Andrew Morton wrote: > I've rather lost the plot with this little patch. Is the below > suitable, or do we think that changes are needed? > > > From: Michal Hocko > Subject: mm: clarify __GFP_MEMALLOC usage > > It seems that the existing documentation is not explicit about the > expected usage and potential risks enough. While it is calls out that > users have to free memory when using this flag it is not really apparent > that users have to careful to not deplete memory reserves and that they > should implement some sort of throttling wrt. freeing process. > > This is partly based on Neil's explanation [1]. > > Let's also call out that a pre allocated pool allocator should be > considered. > > [1] http://lkml.kernel.org/r/877dz0yxoa.fsf@notabene.neil.brown.name > > [akpm@linux-foundation.org: coding style fixes] > Link: http://lkml.kernel.org/r/20200403083543.11552-2-mhocko@kernel.org > Signed-off-by: Michal Hocko > Cc: David Rientjes > Cc: Joel Fernandes > Cc: Neil Brown > Cc: Paul E. McKenney > Cc: John Hubbard > [mhocko@kernel.org: update] > Link: http://lkml.kernel.org/r/20200406070137.GC19426@dhcp22.suse.cz > Signed-off-by: Andrew Morton > --- > > include/linux/gfp.h | 5 +++++ > 1 file changed, 5 insertions(+) > > --- a/include/linux/gfp.h~mm-clarify-__gfp_memalloc-usage > +++ a/include/linux/gfp.h > @@ -110,6 +110,11 @@ struct vm_area_struct; > * the caller guarantees the allocation will allow more memory to be freed > * very shortly e.g. process exiting or swapping. Users either should > * be the MM or co-ordinating closely with the VM (e.g. swap over NFS). > + * Users of this flag have to be extremely careful to not deplete the reserve > + * completely and implement a throttling mechanism which controls the > + * consumption of the reserve based on the amount of freed memory. > + * Usage of a pre-allocated pool (e.g. mempool) should be always considered > + * before using this flag. I particularly don't like the connection between the consumption and the amount freed. I don't think that say anything useful and it misses the main point which, I think, is having a bound on total usage. Nichal's previous proposal is, I think, the best concrete proposal so far. NeilBrown > * > * %__GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves. > * This takes precedence over the %__GFP_MEMALLOC flag if both are set. > _ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAl6VNGkACgkQOeye3VZi gbmUqw/+IOvlNMYdYcojRcEW8VsmDaByc7Fki5Jdl5TdAVpGjzkO5hvJmpJ/kegK Sp3MFIDL0ZKCSXLR5oMivlxj9fs3Kp0hSZKakT3HGb4rKOPtvrdOlEJwtK2n8QuZ WG3gUivxitP/jVra95l0YMjWdByaks1A2LUuCkSRFXTbXxNCbTtsejOSQZ1nHNmw aNDPza3HVLBTs/7C1ddI9yERlangq2OpTRneubVRA8b92naJ7eszVnree/U0C+YK LlhfsBoHe/VR6US2Ow5Z8O+d3S73+a71q+6RKfJFjwRRIkVih+j9aWMZS0kwvW5h zavZiWweRw9naOvm2i4VR+09Lyo3GJmMDLAAvgdGTE8wR7bzQ3dh2pKG5llhnWvB MFyyru3xl3kwcb7MnAU9wPTraK17P6IDzjHdIHfYv/hge5QvO6kvJUpYkOaRke1c ZTK9pzNsaFn16d0mbktyAadIXZ05md0DZ4uFr0Yz36RoOWL4YP7mo5TMM/ZXkTPc AXlAY2YnXrEhGazhNTv8cJFqgmpaydcYPDoFX6KbeUYXMtGlwDvTgN8O18bXruGr Z7C/M5C4Xbxr5y/ZST5VrgY61oYQeOSMzQ0TXpH0OCEx7luaFQYs+KMU1QynsWDS lS/vwruSb7QjUy5xSAUru2sOGgeEQe4tAALoCVaChEL0QU3e/RI= =6JJt -----END PGP SIGNATURE----- --=-=-=--