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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7463DC433EF for ; Wed, 1 Jun 2022 17:30:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355752AbiFARaM convert rfc822-to-8bit (ORCPT ); Wed, 1 Jun 2022 13:30:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356319AbiFARaD (ORCPT ); Wed, 1 Jun 2022 13:30:03 -0400 Received: from cloud48395.mywhc.ca (cloud48395.mywhc.ca [173.209.37.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CF0F78EFD for ; Wed, 1 Jun 2022 10:30:00 -0700 (PDT) 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: 8BIT 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 - vger.kernel.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: Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org 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... > > > > Why does out_of_memory() requires GFP_FS to kill a process? AFAIK, > > no > > filesystem-dependent operations are needed to kill a process... > > 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. > >                                                                 Honza 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...