On Tue, Sep 17, 2019 at 12:52 AM Miklos Szeredi wrote: > > On Tue, Sep 17, 2019 at 1:56 AM Khazhismel Kumykov wrote: > > struct fuse_forget_link *fuse_alloc_forget(void) > > { > > - return kzalloc(sizeof(struct fuse_forget_link), GFP_KERNEL); > > + return kzalloc(sizeof(struct fuse_forget_link), > > + GFP_KERNEL_ACCOUNT | __GFP_RECLAIMABLE); > > What does __GFP_RECLAIMBALE signify in slab allocs? > Marking these allocations reclaimable hints to mm how much we can reclaim overall by shrinking, so if it is reclaimable we should mark it as such. For d_fsdata, the lifetime is linked to the dentry, which is reclaimable, so it makes sense here. > You understand that the forget_link is not reclaimable in the sense, > that it requires action (reading requests from the fuse device) from > the userspace filesystem daemon? > Ah, I see, whenever we evict the fuse_inode, we queue a forget command, which usually waits for userspace. So it's not actually linked to the inode itself, and yeah, if we need userspace to intervene we shouldn't treat forget_link as reclaimable. I had figured since fuse_inode is reclaimable, this should be too, but missed that disconnect, thanks.