Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Removing GFP_NOFS

[Viacheslav Dubeyko <slava@dubeyko.com>]

> On Jan 5, 2024, at 1:26 PM, Jan Kara <jack@suse.cz> wrote:
> 
> On Fri 05-01-24 13:13:11, Viacheslav Dubeyko wrote:
>> 
>> 
>>> On Jan 5, 2024, at 12:17 AM, Matthew Wilcox <willy@infradead.org> wrote:
>>> 
>>> This is primarily a _FILESYSTEM_ track topic.  All the work has already
>>> been done on the MM side; the FS people need to do their part.  It could
>>> be a joint session, but I'm not sure there's much for the MM people
>>> to say.
>>> 
>>> There are situations where we need to allocate memory, but cannot call
>>> into the filesystem to free memory.  Generally this is because we're
>>> holding a lock or we've started a transaction, and attempting to write
>>> out dirty folios to reclaim memory would result in a deadlock.
>>> 
>>> The old way to solve this problem is to specify GFP_NOFS when allocating
>>> memory.  This conveys little information about what is being protected
>>> against, and so it is hard to know when it might be safe to remove.
>>> It's also a reflex -- many filesystem authors use GFP_NOFS by default
>>> even when they could use GFP_KERNEL because there's no risk of deadlock.
>>> 
>>> The new way is to use the scoped APIs -- memalloc_nofs_save() and
>>> memalloc_nofs_restore().  These should be called when we start a
>>> transaction or take a lock that would cause a GFP_KERNEL allocation to
>>> deadlock.  Then just use GFP_KERNEL as normal.  The memory allocators
>>> can see the nofs situation is in effect and will not call back into
>>> the filesystem.
>>> 
>>> This results in better code within your filesystem as you don't need to
>>> pass around gfp flags as much, and can lead to better performance from
>>> the memory allocators as GFP_NOFS will not be used unnecessarily.
>>> 
>>> The memalloc_nofs APIs were introduced in May 2017, but we still have
>>> over 1000 uses of GFP_NOFS in fs/ today (and 200 outside fs/, which is
>>> really sad).  This session is for filesystem developers to talk about
>>> what they need to do to fix up their own filesystem, or share stories
>>> about how they made their filesystem better by adopting the new APIs.
>>> 
>> 
>> Many file systems are still heavily using GFP_NOFS for kmalloc and
>> kmem_cache_alloc family methods even if  memalloc_nofs_save() and
>> memalloc_nofs_restore() pair is used too. But I can see that GFP_NOFS
>> is used in radix_tree_preload(), bio_alloc(), posix_acl_clone(),
>> sb_issue_zeroout, sb_issue_discard(), alloc_inode_sb(), blkdev_issue_zeroout(),
>> blkdev_issue_secure_erase(), blkdev_zone_mgmt(), etc.
> 
> Given the nature of the scoped API, the transition has to start in the
> leaves (i.e. filesystems itself) and only once all users of say
> radix_tree_preload() are converted to the scoped API, we can remove the
> GFP_NOFS use from radix_tree_preload() itself. So Matthew is right that we
> need to start in the filesystems.

Makes sense to me. So, we need to summarize which file system uses
the GFP_NOFS for which methods. Then, I assume, it will be possible
to split the whole modification for particular phases of getting rid of
GFP_NOFS in particular case (particular method). It looks like that
we need to declare the whole modification plan and something like
a schedule for such change. Would it work in such way? :)

Thanks,
Slava.