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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A5D2C43334 for ; Wed, 1 Jun 2022 17:30:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1B538D0029; Wed, 1 Jun 2022 13:30:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC7728D0028; Wed, 1 Jun 2022 13:30:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB3F28D0029; Wed, 1 Jun 2022 13:30:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9CBD28D0028 for ; Wed, 1 Jun 2022 13:30:00 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 1F7AE1211C8 for ; Wed, 1 Jun 2022 17:30:00 +0000 (UTC) X-FDA: 79530354960.12.2E9813D Received: from cloud48395.mywhc.ca (cloud48395.mywhc.ca [173.209.37.211]) by imf10.hostedemail.com (Postfix) with ESMTP id C5717C006A for ; Wed, 1 Jun 2022 17:29:15 +0000 (UTC) Received: from [45.44.224.220] (port=40682 helo=[192.168.1.179]) by cloud48395.mywhc.ca with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1nwSAP-000142-Ov; Wed, 01 Jun 2022 13:29:57 -0400 Message-ID: <32fa2fa1db1adcc3c60974fa84a88c74aad82cae.camel@trillion01.com> Subject: Re: [PATCH v6 04/16] iomap: Add flags parameter to iomap_page_create() From: Olivier Langlois To: Jan Kara Cc: "Darrick J. Wong" , Stefan Roesch , io-uring@vger.kernel.org, kernel-team@fb.com, linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, david@fromorbit.com, hch@infradead.org Date: Wed, 01 Jun 2022 13:29:55 -0400 In-Reply-To: <20220601082131.rem4qaqabu4ktofl@quack3.lan> References: <20220526173840.578265-1-shr@fb.com> <20220526173840.578265-5-shr@fb.com> <12a76c029e9f3cac279c025776dfb2f59331dca0.camel@olivierlanglois.net> <20220601082131.rem4qaqabu4ktofl@quack3.lan> Organization: Trillion01 Inc Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.1 MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud48395.mywhc.ca X-AntiAbuse: Original Domain - kvack.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - trillion01.com X-Get-Message-Sender-Via: cloud48395.mywhc.ca: authenticated_id: olivier@trillion01.com X-Authenticated-Sender: cloud48395.mywhc.ca: olivier@trillion01.com X-Source: X-Source-Args: X-Source-Dir: X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of olivier@trillion01.com designates 173.209.37.211 as permitted sender) smtp.mailfrom=olivier@trillion01.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C5717C006A X-Stat-Signature: nrpadud4zd19e3jidso1weznmcmodh7f X-HE-Tag: 1654104555-408045 X-Bogosity: Ham, tests=bogofilter, spamicity=0.143280, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 2022-06-01 at 10:21 +0200, Jan Kara wrote: > > I have a question that is a bit offtopic but since it is concerning > > GFP > > flags and this is what is discussed here maybe a participant will > > kindly give me some hints about this mystery that has burned me for > > so > > long... > >=20 > > Why does out_of_memory() requires GFP_FS to kill a process? AFAIK, > > no > > filesystem-dependent operations are needed to kill a process... >=20 > AFAIK it is because without GFP_FS, the chances for direct reclaim > are > fairly limited so we are not sure whether the machine is indeed out > of > memory or whether it is just that we need to reclaim from fs pools to > free > up memory. >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Honza Jan, thx a lot for this lead. I will study it further. Your answer made me realized that the meaning of direct reclaim was not crystal clear to me. I'll return to my Bovet & Cesati book to clear that out (That is probably the book in my bookshelf that I have read the most). After having sending out my question, I have came up with another possible explanation... Maybe it is not so much to send the killing signal to the oom victim that requires GFP_FS but maybe the trouble the condition is avoiding is the oom victim process trying to return memory to VFS as it exits while VFS is busy waiting for its allocation request to succeed...