Re: [PATCH v3 2/2] fuse: kmemcg account fs data

From: Miklos Szeredi
Date: Tue Sep 17 2019 - 03:52:27 EST


On Tue, Sep 17, 2019 at 1:56 AM Khazhismel Kumykov <khazhy@xxxxxxxxxx> wrote:
>
> account per-file, dentry, and inode data
>
> blockdev/superblock and temporary per-request data was left alone, as
> this usually isn't accounted
>
> Signed-off-by: Khazhismel Kumykov <khazhy@xxxxxxxxxx>
> Reviewed-by: Shakeel Butt <shakeelb@xxxxxxxxxx>
> ---
> fs/fuse/dir.c | 3 ++-
> fs/fuse/file.c | 5 +++--
> fs/fuse/inode.c | 3 ++-
> 3 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index 58557d4817e9..d572c900bb0f 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -279,7 +279,8 @@ static int fuse_dentry_revalidate(struct dentry *entry, unsigned int flags)
> #if BITS_PER_LONG < 64
> static int fuse_dentry_init(struct dentry *dentry)
> {
> - dentry->d_fsdata = kzalloc(sizeof(union fuse_dentry), GFP_KERNEL);
> + dentry->d_fsdata = kzalloc(sizeof(union fuse_dentry),
> + GFP_KERNEL_ACCOUNT | __GFP_RECLAIMABLE);
>
> return dentry->d_fsdata ? 0 : -ENOMEM;
> }
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index a2ea347c4d2c..862aff3665b5 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -63,12 +63,13 @@ struct fuse_file *fuse_file_alloc(struct fuse_conn *fc)
> {
> struct fuse_file *ff;
>
> - ff = kzalloc(sizeof(struct fuse_file), GFP_KERNEL);
> + ff = kzalloc(sizeof(struct fuse_file), GFP_KERNEL_ACCOUNT);
> if (unlikely(!ff))
> return NULL;
>
> ff->fc = fc;
> - ff->release_args = kzalloc(sizeof(*ff->release_args), GFP_KERNEL);
> + ff->release_args = kzalloc(sizeof(*ff->release_args),
> + GFP_KERNEL_ACCOUNT);
> if (!ff->release_args) {
> kfree(ff);
> return NULL;
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index 3d598a5bb5b5..6cb445bed89d 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -66,7 +66,8 @@ static struct file_system_type fuseblk_fs_type;
>
> 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?

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?

Thanks,
Miklos