On Wed 23-03-22 16:00:30, Amir Goldstein wrote: > > Well, but reclaim from kswapd is always the main and preferred source of > > memory reclaim. And we will kick kswapd to do work if we are running out of > > memory. Doing direct filesystem slab reclaim from mark allocation is useful > > only to throttle possibly aggressive mark allocations to the speed of > > reclaim (instead of getting ENOMEM). So I'm still not convinced this is a > > big issue but I certainly won't stop you from implementing more fine > > grained GFP mode selection and lockdep annotations if you want to go that > > way :). > > Well it was just two lines of code to annotate the fanotify mutex as its own > class, so I just did that: > > https://github.com/amir73il/linux/commit/7b4b6e2c0bd1942cd130e9202c4b187a8fb468c6 But this implicitely assumes there isn't any allocation under mark_mutex anywhere else where it is held. Which is likely true (I didn't check) but it is kind of fragile. So I was rather imagining we would have per-group "NOFS" flag and fsnotify_group_lock/unlock() would call memalloc_nofs_save() based on the flag. And we would use fsnotify_group_lock/unlock() uniformly across the whole fsnotify codebase. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
