On Fri 05-01-24 13:13:11, Viacheslav Dubeyko wrote: > > > > On Jan 5, 2024, at 12:17 AM, Matthew Wilcox <willy@xxxxxxxxxxxxx> 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. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
