Re: [PATCH v6 04/16] iomap: Add flags parameter to iomap_page_create()

[Jan Kara <jack@suse.cz>]

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 <jack@suse.com>
SUSE Labs, CR