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 84DE7C433EF for ; Wed, 1 Jun 2022 08:21:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350570AbiFAIVl (ORCPT ); Wed, 1 Jun 2022 04:21:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348724AbiFAIVi (ORCPT ); Wed, 1 Jun 2022 04:21:38 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 222638BD09; Wed, 1 Jun 2022 01:21:34 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id A0F1E1F8C2; Wed, 1 Jun 2022 08:21:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1654071692; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qFW9bTmKBS2+gHojijvkjkqL/6eg0hnOyIs9tcdOTgY=; b=rzKGxBWKlTdfgQJeou5aTTP3eotyRDYh0h5IgTWh9X3T+mol14UPDdeW5WuJUV+JsJB05q hg+x/HZjYhAN/WUl3jiDHvDs2Sp7G+waBsH5Ktd5/7foaZIrGmYPyuC8Kw3lap9xjfIzXe iSUu/C/rSN/RCW9CWT4kmiOirvokkyI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1654071692; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qFW9bTmKBS2+gHojijvkjkqL/6eg0hnOyIs9tcdOTgY=; b=8O8b/MlDnnsYqt5E0buDIbYgfGJz2wStygFZ2QukhPHcEQ55VrhQiN9iweqFDlO2zvWGOr lRTj5r4fXMNxE4BA== Received: from quack3.suse.cz (unknown [10.163.28.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 6A6D42C141; Wed, 1 Jun 2022 08:21:32 +0000 (UTC) Received: by quack3.suse.cz (Postfix, from userid 1000) id 08F35A0633; Wed, 1 Jun 2022 10:21:32 +0200 (CEST) Date: Wed, 1 Jun 2022 10:21:31 +0200 From: Jan Kara To: Olivier Langlois 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, jack@suse.cz, hch@infradead.org Subject: Re: [PATCH v6 04/16] iomap: Add flags parameter to iomap_page_create() Message-ID: <20220601082131.rem4qaqabu4ktofl@quack3.lan> References: <20220526173840.578265-1-shr@fb.com> <20220526173840.578265-5-shr@fb.com> <12a76c029e9f3cac279c025776dfb2f59331dca0.camel@olivierlanglois.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12a76c029e9f3cac279c025776dfb2f59331dca0.camel@olivierlanglois.net> Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Tue 31-05-22 20:34:20, Olivier Langlois wrote: > On Thu, 2022-05-26 at 11:25 -0700, Darrick J. Wong wrote: > > On Thu, May 26, 2022 at 10:38:28AM -0700, Stefan Roesch wrote: > > > > > >  static struct iomap_page * > > > -iomap_page_create(struct inode *inode, struct folio *folio) > > > +iomap_page_create(struct inode *inode, struct folio *folio, > > > unsigned int flags) > > >  { > > >         struct iomap_page *iop = to_iomap_page(folio); > > >         unsigned int nr_blocks = i_blocks_per_folio(inode, folio); > > > +       gfp_t gfp = GFP_NOFS | __GFP_NOFAIL; > > >   > > >         if (iop || nr_blocks <= 1) > > >                 return iop; > > >   > > > +       if (flags & IOMAP_NOWAIT) > > > +               gfp = GFP_NOWAIT; > > > > Hmm.  GFP_NOWAIT means we don't wait for reclaim or IO or filesystem > > callbacks, and NOFAIL means we retry indefinitely.  What happens in > > the > > NOWAIT|NOFAIL case?  Does that imply that the kzalloc loops without > > triggering direct reclaim until someone else frees enough memory? > > > > --D > > 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 Kara SUSE Labs, CR