Re: [PATCH v2 3/3] fs: fsnotify: account fsnotify metadata to kmemcg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 20 Feb 2018, Shakeel Butt wrote:

> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 6702a6a0bbb5..0d9493ebc7cd 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
>  	if (fanotify_is_perm_event(mask)) {
>  		struct fanotify_perm_event_info *pevent;
>
> -		pevent = kmem_cache_alloc(fanotify_perm_event_cachep,
> -					  GFP_KERNEL);
> +		pevent = kmem_cache_alloc_memcg(fanotify_perm_event_cachep,
> +						GFP_KERNEL, memcg);
>  		if (!pevent)

#1

> index 8b73332735ba..ed8e7b5f3981 100644
> --- a/fs/notify/inotify/inotify_fsnotify.c
> +++ b/fs/notify/inotify/inotify_fsnotify.c
> @@ -98,7 +98,7 @@ int inotify_handle_event(struct fsnotify_group *group,
>  	i_mark = container_of(inode_mark, struct inotify_inode_mark,
>  			      fsn_mark);
>
> -	event = kmalloc(alloc_len, GFP_KERNEL);
> +	event = kmalloc_memcg(alloc_len, GFP_KERNEL, group->memcg);
>  	if (unlikely(!event))
>  		return -ENOMEM;

#2


So we have all this churn for those two allocations which are basically
the same code for two different notification schemes.

Could you store the task that is requesting the fsnotify action instead of
the memcg? Then do the allocation in the context of that task. That
reduces the modifications to fsnotify.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux