> On Jan 5, 2024, at 1:26 PM, Jan Kara <jack@xxxxxxx> wrote: > > 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. 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.
