Directed kmem charging
Subsystems (11)
v8 cover Directed kmem charging
The Linux kernel's memory cgroup allows limiting the memory usage of the jobs running on the system to provide isolation between the jobs. All the kernel memory allocated in the context of the job and marked with __GFP_ACCOUNT will also be included in the memory usage and be limited by the job's limit.
The kernel memory can only be charged to the memcg of the process in whose context kernel memory was allocated. However there are cases where the allocated kernel memory should be charged to the memcg different from the current processes's memcg. This patch series contains two such concrete use-cases i.e. fsnotify and buffer_head.
The fsnotify event objects can consume a lot of system memory for large or unlimited queues if there is either no or slow listener. The events are allocated in the context of the event producer. However they should be charged to the event consumer. Similarly the buffer_head objects can be allocated in a memcg different from the memcg of the page for which buffer_head objects are being allocated.
To solve this issue, this patch series introduces mechanism to charge kernel memory to a given memcg. In case of fsnotify events, the memcg of the consumer can be used for charging and for buffer_head, the memcg of the page can be charged. For directed charging, the caller can use the scope API memalloc_[un]use_memcg() to specify the memcg to charge for all the __GFP_ACCOUNT allocations within the scope.
Shakeel Butt (2):
fs: fsnotify: account fsnotify metadata to kmemcg fs, mm: account buffer_head to kmemcg
fs/buffer.c | 15 ++++++- fs/notify/dnotify/dnotify.c | 5 ++- fs/notify/fanotify/fanotify.c | 17 ++++++-- fs/notify/fanotify/fanotify_user.c | 5 ++- fs/notify/group.c | 4 ++ fs/notify/inotify/inotify_fsnotify.c | 15 ++++++- fs/notify/inotify/inotify_user.c | 5 ++- include/linux/fsnotify_backend.h | 12 ++++-- include/linux/memcontrol.h | 14 +++++++ include/linux/sched.h | 3 ++ include/linux/sched/mm.h | 41 +++++++++++++++++++ kernel/fork.c | 3 ++ mm/memcontrol.c | 60 ++++++++++++++++++++++++++-- 13 files changed, 182 insertions(+), 17 deletions(-)
Signature · 1 line
2.18.0.rc2.346.g013aa6912e-goog
PATCH v8 1/2 fs: fsnotify: account fsnotify metadata to kmemcg
A lot of memory can be consumed by the events generated for the huge or unlimited queues if there is either no or slow listener. This can cause system level memory pressure or OOMs. So, it's better to account the fsnotify kmem caches to the memcg of the listener.
However the listener can be in a different memcg than the memcg of the producer and these allocations happen in the context of the event producer. This patch introduces remote memcg charging API which the producer can use to charge the allocations to the memcg of the listener.
There are seven fsnotify kmem caches and among them allocations from dnotify_struct_cache, dnotify_mark_cache, fanotify_mark_cache and inotify_inode_mark_cachep happens in the context of syscall from the listener. So, SLAB_ACCOUNT is enough for these caches.
The objects from fsnotify_mark_connector_cachep are not accounted as they are small compared to the notification mark or events and it is unclear whom to account connector to since it is shared by all events attached to the inode.
The allocations from the event caches happen in the context of the event producer. For such caches we will need to remote charge the allocations to the listener's memcg. Thus we save the memcg reference in the fsnotify_group structure of the listener.
This patch has also moved the members of fsnotify_group to keep the size same, at least for 64 bit build, even with additional member by filling the holes.
---
Changelog since v7:
- Simplify the remote memcg charging API
- get_mem_cgroup_from_current() returns root_mem_cgroup if current->active_memcg is not NULL but css_tryget_online() fails.
Changelog since v6:
- Removed Jan's ACK as the code has changed a lot
- Squashed the separate remote charging API path into this one
- Removed kmalloc* & kmem_cache_alloc* APIs and only kept the scope API
- Changed fsnotify remote charging code to use scope API
Changelog since v5:
- None
Changelog since v4:
- Fixed the build for CONFIG_MEMCG=n
Changelog since v3:
- Rebased over Jan's patches.
- Some cleanup based on Amir's comments.
Changelog since v2:
- None
Changelog since v1:
- no more charging fsnotify_mark_connector objects
- Fixed the build for SLOB
fs/notify/dnotify/dnotify.c | 5 ++-- fs/notify/fanotify/fanotify.c | 14 ++++++++--- fs/notify/fanotify/fanotify_user.c | 5 +++- fs/notify/group.c | 3 +++ fs/notify/inotify/inotify_fsnotify.c | 7 +++++- fs/notify/inotify/inotify_user.c | 5 +++- include/linux/fsnotify_backend.h | 12 ++++++--- include/linux/memcontrol.h | 10 +++++++- include/linux/sched.h | 3 +++ include/linux/sched/mm.h | 37 ++++++++++++++++++++++++++++ kernel/fork.c | 3 +++ mm/memcontrol.c | 37 +++++++++++++++++++++++++--- 12 files changed, 123 insertions(+), 18 deletions(-)
fs/notify/dnotify/dnotify.c +3 -2
@@ -384,8 +384,9 @@ int fcntl_dirnotify(int fd, struct file *filp, unsigned long arg)static int __init dnotify_init (void ) { - dnotify_struct_cache =KMEM_CACHE (dnotify_struct,SLAB_PANIC ); - dnotify_mark_cache =KMEM_CACHE (dnotify_mark,SLAB_PANIC ); + dnotify_struct_cache =KMEM_CACHE (dnotify_struct, +SLAB_PANIC |SLAB_ACCOUNT ); + dnotify_mark_cache =KMEM_CACHE (dnotify_mark,SLAB_PANIC |SLAB_ACCOUNT ); dnotify_group =fsnotify_alloc_group (&dnotify_fsnotify_ops);if (IS_ERR (dnotify_group))
fs/notify/fanotify/fanotify.c +10 -4
@@ -11,6 +11,7 @@#include <linux/types.h> #include <linux/wait.h> #include <linux/audit.h> +#include <linux/sched/mm.h> #include "fanotify.h"
@@ -140,8 +141,8 @@ struct fanotify_event_info *fanotify_alloc_event(struct fsnotify_group *group, struct inode *inode, u32 mask, const struct path *path) { - struct fanotify_event_info *event; -gfp_t gfp =GFP_KERNEL ; + struct fanotify_event_info *event = NULL; +gfp_t gfp =GFP_KERNEL | __GFP_ACCOUNT;/* * For queues with unlimited length lost events are not expected and
@@ -151,19 +152,22 @@ struct fanotify_event_info *fanotify_alloc_event(struct fsnotify_group *group,if (group->max_events ==UINT_MAX ) gfp |= __GFP_NOFAIL; +/* Whoever is interested in the event, pays for the allocation. */ +memalloc_use_memcg (group->memcg); +if (fanotify_is_perm_event (mask)) {struct fanotify_perm_event_info *pevent; pevent =kmem_cache_alloc (fanotify_perm_event_cachep, gfp);if (!pevent) -return NULL ; + goto out; event = &pevent->fae; pevent->response =0 ; goto init; } event =kmem_cache_alloc (fanotify_event_cachep, gfp);if (!event) -return NULL ; + goto out; init:__maybe_unused fsnotify_init_event (&event->fse, inode, mask); event->tgid =get_pid (task_tgid (current));
@@ -174,6 +178,8 @@ init: __maybe_unused event->path.mnt =NULL ; event->path.dentry =NULL ; } +out: +memalloc_unuse_memcg ();return event; }
fs/notify/fanotify/fanotify_user.c +4 -1
@@ -16,6 +16,7 @@#include <linux/uaccess.h> #include <linux/compat.h> #include <linux/sched/signal.h> +#include <linux/memcontrol.h> #include <asm/ioctls.h>
@@ -756,6 +757,7 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, unsigned int, event_f_flags) group->fanotify_data.user = user;atomic_inc (&user->fanotify_listeners); + group->memcg =get_mem_cgroup_from_mm (current->mm); oevent =fanotify_alloc_event (group,NULL ,FS_Q_OVERFLOW ,NULL );if (unlikely (!oevent)) {
@@ -957,7 +959,8 @@ COMPAT_SYSCALL_DEFINE6(fanotify_mark,*/ static int __init fanotify_user_setup (void ) { - fanotify_mark_cache =KMEM_CACHE (fsnotify_mark,SLAB_PANIC ); + fanotify_mark_cache =KMEM_CACHE (fsnotify_mark, +SLAB_PANIC |SLAB_ACCOUNT ); fanotify_event_cachep =KMEM_CACHE (fanotify_event_info,SLAB_PANIC );if (IS_ENABLED (CONFIG_FANOTIFY_ACCESS_PERMISSIONS )) { fanotify_perm_event_cachep =
fs/notify/group.c +3 -0
@@ -22,6 +22,7 @@#include <linux/srcu.h> #include <linux/rculist.h> #include <linux/wait.h> +#include <linux/memcontrol.h> #include <linux/fsnotify_backend.h> #include "fsnotify.h"
@@ -36,6 +37,8 @@ static void fsnotify_final_destroy_group(struct fsnotify_group *group)if (group->ops->free_group_priv) group->ops->free_group_priv (group); +mem_cgroup_put (group->memcg); +kfree (group); }
fs/notify/inotify/inotify_fsnotify.c +6 -1
@@ -31,6 +31,7 @@#include <linux/types.h> #include <linux/sched.h> #include <linux/sched/user.h> +#include <linux/sched/mm.h> #include "inotify.h"
@@ -98,7 +99,11 @@ 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 ); +/* Whoever is interested in the event, pays for the allocation. */ +memalloc_use_memcg (group->memcg); + event =kmalloc (alloc_len,GFP_KERNEL | __GFP_ACCOUNT); +memalloc_unuse_memcg (); +if (unlikely (!event)) {/* * Treat lost event due to ENOMEM the same way as queue
fs/notify/inotify/inotify_user.c +4 -1
@@ -38,6 +38,7 @@#include <linux/uaccess.h> #include <linux/poll.h> #include <linux/wait.h> +#include <linux/memcontrol.h> #include "inotify.h" #include "../fdinfo.h"
@@ -636,6 +637,7 @@ static struct fsnotify_group *inotify_new_group(unsigned int max_events) oevent->name_len =0 ; group->max_events = max_events; + group->memcg =get_mem_cgroup_from_mm (current->mm);spin_lock_init (&group->inotify_data.idr_lock);idr_init (&group->inotify_data.idr);
@@ -808,7 +810,8 @@ static int __init inotify_user_setup(void)BUG_ON (hweight32 (ALL_INOTIFY_BITS ) !=21 ); - inotify_inode_mark_cachep =KMEM_CACHE (inotify_inode_mark,SLAB_PANIC ); + inotify_inode_mark_cachep =KMEM_CACHE (inotify_inode_mark, +SLAB_PANIC |SLAB_ACCOUNT ); inotify_max_queued_events =16384 ; init_user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES ] =128 ;
include/linux/fsnotify_backend.h +8 -4
@@ -84,6 +84,8 @@ struct fsnotify_event_private_data;struct fsnotify_fname ;struct fsnotify_iter_info ; +struct mem_cgroup ; +/* * Each group much define these ops. The fsnotify infrastructure will call * these operations for each relevant group.
@@ -127,6 +129,8 @@ struct fsnotify_event {* everything will be cleaned up. */ struct fsnotify_group { +const struct fsnotify_ops *ops;/* how this group handles things */ +/* * How the refcnt is used is up to each group. When the refcnt hits 0 * fsnotify will clean up all of the resources associated with this group.
@@ -137,8 +141,6 @@ struct fsnotify_group {*/ refcount_t refcnt;/* things with interest in this group */ -const struct fsnotify_ops *ops;/* how this group handles things */ -/* needed to send notification to userspace */ spinlock_t notification_lock;/* protect the notification_list */ struct list_head notification_list;/* list of event_holder this group needs to send to userspace */
@@ -160,6 +162,8 @@ struct fsnotify_group {atomic_t num_marks;/* 1 for each mark and 1 for not being * past the point of no return when freeing * a group */ +atomic_t user_waits;/* Number of tasks waiting for user +* response */ struct list_head marks_list;/* all inode marks for this group */ struct fasync_struct *fsn_fa;/* async notification */
@@ -167,8 +171,8 @@ struct fsnotify_group {struct fsnotify_event *overflow_event;/* Event we queue when the * notification list is too * full */ -atomic_t user_waits;/* Number of tasks waiting for user -* response */ + +struct mem_cgroup *memcg;/* memcg to charge allocations */ /* groups can define private fields here or use the void *private */ union {
include/linux/memcontrol.h +9 -1
@@ -378,6 +378,8 @@ struct lruvec *mem_cgroup_page_lruvec(struct page *, struct pglist_data *);bool task_in_mem_cgroup (struct task_struct *task,struct mem_cgroup *memcg);struct mem_cgroup *mem_cgroup_from_task (struct task_struct *p); +struct mem_cgroup *get_mem_cgroup_from_mm (struct mm_struct *mm); +static inline struct mem_cgroup *mem_cgroup_from_css (struct cgroup_subsys_state *css){ return css ? container_of(css, struct mem_cgroup, css) : NULL;
@@ -385,7 +387,8 @@ struct mem_cgroup *mem_cgroup_from_css(struct cgroup_subsys_state *css){static inline void mem_cgroup_put (struct mem_cgroup *memcg) { -css_put (&memcg->css); +if (memcg) +css_put (&memcg->css); }#define mem_cgroup_from_counter (counter, member) \
@@ -857,6 +860,11 @@ static inline bool task_in_mem_cgroup(struct task_struct *task,return true; } +static inline struct mem_cgroup *get_mem_cgroup_from_mm (struct mm_struct *mm) +{ +return NULL ; +} +static inline void mem_cgroup_put (struct mem_cgroup *memcg) { }
include/linux/sched.h +3 -0
@@ -1149,6 +1149,9 @@ struct task_struct {/* Number of pages to reclaim on returning to userland: */ unsigned int memcg_nr_pages_over_high; + +/* Used by memcontrol for targeted memcg charge: */ +struct mem_cgroup *active_memcg;#endif #ifdef CONFIG_UPROBES
include/linux/sched/mm.h +37 -0
@@ -248,6 +248,43 @@ static inline void memalloc_noreclaim_restore(unsigned int flags) current->flags = (current->flags & ~PF_MEMALLOC ) | flags; } +#ifdef CONFIG_MEMCG +/** +* memalloc_use_memcg - Starts the remote memcg charging scope. +* @memcg: memcg to charge. +* +* This function marks the beginning of the remote memcg charging scope. All the +* __GFP_ACCOUNT allocations till the end of the scope will be charged to the +* given memcg. +* +* NOTE: This function is not nesting safe. +*/ +static inline void memalloc_use_memcg (struct mem_cgroup *memcg) +{ +WARN_ON_ONCE (current->active_memcg); + current->active_memcg = memcg; +} + +/** +* memalloc_unuse_memcg - Ends the remote memcg charging scope. +* +* This function marks the end of the remote memcg charging scope started by +* memalloc_use_memcg(). +*/ +static inline void memalloc_unuse_memcg (void ) +{ + current->active_memcg =NULL ; +} +#else +static inline void memalloc_use_memcg (struct mem_cgroup *memcg) +{ +} + +static inline void memalloc_unuse_memcg (void ) +{ +} +#endif +#ifdef CONFIG_MEMBARRIER enum { MEMBARRIER_STATE_PRIVATE_EXPEDITED_READY = (1U << 0),
kernel/fork.c +3 -0
@@ -843,6 +843,9 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node) tsk->fail_nth =0 ;#endif +#ifdef CONFIG_MEMCG + tsk->active_memcg =NULL ; +#endif return tsk; free_stack:
mm/memcontrol.c +33 -4
@@ -678,9 +678,20 @@ struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p) }EXPORT_SYMBOL (mem_cgroup_from_task); -static struct mem_cgroup *get_mem_cgroup_from_mm (struct mm_struct *mm) +/** +* get_mem_cgroup_from_mm: Obtain a reference on given mm_struct's memcg. +* @mm: mm from which memcg should be extracted. It can be NULL. +* +* Obtain a reference on mm->memcg and returns it if successful. Otherwise +* root_mem_cgroup is returned. However if mem_cgroup is disabled, NULL is +* returned. +*/ +struct mem_cgroup *get_mem_cgroup_from_mm (struct mm_struct *mm) { -struct mem_cgroup *memcg =NULL ; +struct mem_cgroup *memcg; + +if (mem_cgroup_disabled ()) +return NULL ;rcu_read_lock (); do {
@@ -700,6 +711,24 @@ static struct mem_cgroup *get_mem_cgroup_from_mm(struct mm_struct *mm)rcu_read_unlock ();return memcg; } +EXPORT_SYMBOL (get_mem_cgroup_from_mm); + +/** +* If current->active_memcg is non-NULL, do not fallback to current->mm->memcg. +*/ +static __always_inline struct mem_cgroup *get_mem_cgroup_from_current(void) +{ +if (unlikely (current->active_memcg)) { +struct mem_cgroup *memcg = root_mem_cgroup; + +rcu_read_lock (); +if (css_tryget_online (¤t->active_memcg->css)) + memcg = current->active_memcg; +rcu_read_unlock (); +return memcg; + } +return get_mem_cgroup_from_mm (current->mm); +}/** * mem_cgroup_iter - iterate over memory cgroup hierarchy
@@ -2260,7 +2289,7 @@ struct kmem_cache *memcg_kmem_get_cache(struct kmem_cache *cachep)if (current->memcg_kmem_skip_account)return cachep; - memcg =get_mem_cgroup_from_mm (current->mm); + memcg =get_mem_cgroup_from_current (); kmemcg_id =READ_ONCE (memcg->kmemcg_id);if (kmemcg_id <0 ) goto out;
@@ -2344,7 +2373,7 @@ int memcg_kmem_charge(struct page *page, gfp_t gfp, int order)if (memcg_kmem_bypass ())return 0 ; - memcg =get_mem_cgroup_from_mm (current->mm); + memcg =get_mem_cgroup_from_current ();if (!mem_cgroup_is_root (memcg)) { ret =memcg_kmem_charge_memcg (page, gfp, order, memcg);if (!ret)
Signature · 1 line
2.18.0.rc2.346.g013aa6912e-goog
Jan Kara
maintainerRe: [PATCH 1/2] fs: fsnotify: account fsnotify metadata to kmemcg
Quoted 28 lines · Shakeel Butt
A lot of memory can be consumed by the events generated for the huge or unlimited queues if there is either no or slow listener. This can cause system level memory pressure or OOMs. So, it's better to account the fsnotify kmem caches to the memcg of the listener.
However the listener can be in a different memcg than the memcg of the producer and these allocations happen in the context of the event producer. This patch introduces remote memcg charging API which the producer can use to charge the allocations to the memcg of the listener.
There are seven fsnotify kmem caches and among them allocations from
dnotify_struct_cache,dnotify_mark_cache,fanotify_mark_cacheandinotify_inode_mark_cachephappens in the context of syscall from the listener. So,SLAB_ACCOUNTis enough for these caches.The objects from
fsnotify_mark_connector_cachepare not accounted as they are small compared to the notification mark or events and it is unclear whom to account connector to since it is shared by all events attached to the inode.The allocations from the event caches happen in the context of the event producer. For such caches we will need to remote charge the allocations to the listener's memcg. Thus we save the memcg reference in the
fsnotify_groupstructure of the listener.This patch has also moved the members of
fsnotify_groupto keep the size same, at least for 64 bit build, even with additional member by filling the holes.
...
fs/notify/fanotify/fanotify_user.c COMPAT_SYSCALL_DEFINE6(fanotify_mark, · line 966
Quoted 8 lines
static int
__initfanotify_user_setup(void)
{fs/notify/fanotify/fanotify_user.c +2
-1- fanotify_mark_cache =KMEM_CACHE (fsnotify_mark,SLAB_PANIC ); + fanotify_mark_cache =KMEM_CACHE (fsnotify_mark, +SLAB_PANIC |SLAB_ACCOUNT ); fanotify_event_cachep =KMEM_CACHE (fanotify_event_info,SLAB_PANIC );if (IS_ENABLED (CONFIG_FANOTIFY_ACCESS_PERMISSIONS )) { fanotify_perm_event_cachep =
Why don't you setup also fanotify_event_cachep and fanotify_perm_event_cachep caches with SLAB_ACCOUNT and instead specify __GFP_ACCOUNT manually? Otherwise the patch looks good to me.
Honza
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR
Re: [PATCH 1/2] fs: fsnotify: account fsnotify metadata to kmemcg
Quoted 42 lines · Jan Kara
Quoted 28 lines · Shakeel Butt
A lot of memory can be consumed by the events generated for the huge or unlimited queues if there is either no or slow listener. This can cause system level memory pressure or OOMs. So, it's better to account the fsnotify kmem caches to the memcg of the listener.
However the listener can be in a different memcg than the memcg of the producer and these allocations happen in the context of the event producer. This patch introduces remote memcg charging API which the producer can use to charge the allocations to the memcg of the listener.
There are seven fsnotify kmem caches and among them allocations from
dnotify_struct_cache,dnotify_mark_cache,fanotify_mark_cacheandinotify_inode_mark_cachephappens in the context of syscall from the listener. So,SLAB_ACCOUNTis enough for these caches.The objects from
fsnotify_mark_connector_cachepare not accounted as they are small compared to the notification mark or events and it is unclear whom to account connector to since it is shared by all events attached to the inode.The allocations from the event caches happen in the context of the event producer. For such caches we will need to remote charge the allocations to the listener's memcg. Thus we save the memcg reference in the
fsnotify_groupstructure of the listener.This patch has also moved the members of
fsnotify_groupto keep the size same, at least for 64 bit build, even with additional member by filling the holes....
fs/notify/fanotify/fanotify_user.c COMPAT_SYSCALL_DEFINE6(fanotify_mark, · line 966
Quoted 8 lines
static int
__initfanotify_user_setup(void)
{fs/notify/fanotify/fanotify_user.c +2
-1- fanotify_mark_cache =KMEM_CACHE (fsnotify_mark,SLAB_PANIC ); + fanotify_mark_cache =KMEM_CACHE (fsnotify_mark, +SLAB_PANIC |SLAB_ACCOUNT ); fanotify_event_cachep =KMEM_CACHE (fanotify_event_info,SLAB_PANIC );if (IS_ENABLED (CONFIG_FANOTIFY_ACCESS_PERMISSIONS )) { fanotify_perm_event_cachep =
Quoted 4 lines
Why don't you setup also
fanotify_event_cachepandfanotify_perm_event_cachepcaches withSLAB_ACCOUNTand instead specify__GFP_ACCOUNTmanually? Otherwise the patch looks good to me.
Hi Jan, IMHO having a visible __GFP_ACCOUNT along with memalloc_use_memcg() makes the code more explicit and readable that we want to targeted/remote memcg charging. However if you think otherwise, I will replace __GFP_ACCOUNT with SLAB_ACCOUNT.
thanks,
Shakeel
Michal Hocko
maintainerRe: [PATCH 1/2] fs: fsnotify: account fsnotify metadata to kmemcg
Quoted 43 lines · Shakeel Butt
Quoted 42 lines · Jan Kara
Quoted 28 lines · Shakeel Butt
A lot of memory can be consumed by the events generated for the huge or unlimited queues if there is either no or slow listener. This can cause system level memory pressure or OOMs. So, it's better to account the fsnotify kmem caches to the memcg of the listener.
However the listener can be in a different memcg than the memcg of the producer and these allocations happen in the context of the event producer. This patch introduces remote memcg charging API which the producer can use to charge the allocations to the memcg of the listener.
There are seven fsnotify kmem caches and among them allocations from
dnotify_struct_cache,dnotify_mark_cache,fanotify_mark_cacheandinotify_inode_mark_cachephappens in the context of syscall from the listener. So,SLAB_ACCOUNTis enough for these caches.The objects from
fsnotify_mark_connector_cachepare not accounted as they are small compared to the notification mark or events and it is unclear whom to account connector to since it is shared by all events attached to the inode.The allocations from the event caches happen in the context of the event producer. For such caches we will need to remote charge the allocations to the listener's memcg. Thus we save the memcg reference in the
fsnotify_groupstructure of the listener.This patch has also moved the members of
fsnotify_groupto keep the size same, at least for 64 bit build, even with additional member by filling the holes....
Quoted 8 lines
static int
__initfanotify_user_setup(void)
{fs/notify/fanotify/fanotify_user.c +2
-1- fanotify_mark_cache =KMEM_CACHE (fsnotify_mark,SLAB_PANIC ); + fanotify_mark_cache =KMEM_CACHE (fsnotify_mark, +SLAB_PANIC |SLAB_ACCOUNT ); fanotify_event_cachep =KMEM_CACHE (fanotify_event_info,SLAB_PANIC );if (IS_ENABLED (CONFIG_FANOTIFY_ACCESS_PERMISSIONS )) { fanotify_perm_event_cachep =
Quoted 8 lines
Quoted 4 lines
Why don't you setup also
fanotify_event_cachepandfanotify_perm_event_cachepcaches withSLAB_ACCOUNTand instead specify__GFP_ACCOUNTmanually? Otherwise the patch looks good to me.Hi Jan, IMHO having a visible
__GFP_ACCOUNTalong withmemalloc_use_memcg()makes the code more explicit and readable that we want to targeted/remote memcg charging.
Agreed. If you had an implicit SLAB_ACCOUNT then you could get inconsistencies when some allocations would get charged to the current task while others would not.
Signature · 2 lines
Michal Hocko SUSE Labs
Jan Kara
maintainerRe: [PATCH 1/2] fs: fsnotify: account fsnotify metadata to kmemcg
In reply to Shakeel ButtQuoted 48 lines · Shakeel Butt
Quoted 42 lines · Jan Kara
Quoted 28 lines · Shakeel Butt
A lot of memory can be consumed by the events generated for the huge or unlimited queues if there is either no or slow listener. This can cause system level memory pressure or OOMs. So, it's better to account the fsnotify kmem caches to the memcg of the listener.
However the listener can be in a different memcg than the memcg of the producer and these allocations happen in the context of the event producer. This patch introduces remote memcg charging API which the producer can use to charge the allocations to the memcg of the listener.
There are seven fsnotify kmem caches and among them allocations from
dnotify_struct_cache,dnotify_mark_cache,fanotify_mark_cacheandinotify_inode_mark_cachephappens in the context of syscall from the listener. So,SLAB_ACCOUNTis enough for these caches.The objects from
fsnotify_mark_connector_cachepare not accounted as they are small compared to the notification mark or events and it is unclear whom to account connector to since it is shared by all events attached to the inode.The allocations from the event caches happen in the context of the event producer. For such caches we will need to remote charge the allocations to the listener's memcg. Thus we save the memcg reference in the
fsnotify_groupstructure of the listener.This patch has also moved the members of
fsnotify_groupto keep the size same, at least for 64 bit build, even with additional member by filling the holes....
fs/notify/fanotify/fanotify_user.c COMPAT_SYSCALL_DEFINE6(fanotify_mark, · line 966
Quoted 8 lines
static int
__initfanotify_user_setup(void)
{fs/notify/fanotify/fanotify_user.c +2
-1- fanotify_mark_cache =KMEM_CACHE (fsnotify_mark,SLAB_PANIC ); + fanotify_mark_cache =KMEM_CACHE (fsnotify_mark, +SLAB_PANIC |SLAB_ACCOUNT ); fanotify_event_cachep =KMEM_CACHE (fanotify_event_info,SLAB_PANIC );if (IS_ENABLED (CONFIG_FANOTIFY_ACCESS_PERMISSIONS )) { fanotify_perm_event_cachep =Quoted 4 lines
Why don't you setup also
fanotify_event_cachepandfanotify_perm_event_cachepcaches withSLAB_ACCOUNTand instead specify__GFP_ACCOUNTmanually? Otherwise the patch looks good to me.
Quoted 4 lines
Hi Jan, IMHO having a visible
__GFP_ACCOUNTalong withmemalloc_use_memcg()makes the code more explicit and readable that we want to targeted/remote memcg charging. However if you think otherwise, I will replace__GFP_ACCOUNTwithSLAB_ACCOUNT.
OK, fair enough.
Honza
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR
PATCH 1/1 fs-fsnotify-account-fsnotify-metadata-to-kmemcg.patch.cleanup
In reply to Shakeel ButtHi Andres, this is a small cleanup to the patch "fs: fsnotify: account fsnotify metadata to kmemcg". Please squash.
--- fs/notify/fanotify/fanotify.c | 2 +- fs/notify/inotify/inotify_fsnotify.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
fs/notify/fanotify/fanotify.c +1 -1
@@ -142,7 +142,7 @@ struct fanotify_event_info *fanotify_alloc_event(struct fsnotify_group *group, const struct path *path) {struct fanotify_event_info *event =NULL ; -gfp_t gfp =GFP_KERNEL | __GFP_ACCOUNT; +gfp_t gfp =GFP_KERNEL_ACCOUNT ;/* * For queues with unlimited length lost events are not expected and
fs/notify/inotify/inotify_fsnotify.c +1 -1
@@ -101,7 +101,7 @@ int inotify_handle_event(struct fsnotify_group *group,/* Whoever is interested in the event, pays for the allocation. */ memalloc_use_memcg (group->memcg); - event =kmalloc (alloc_len,GFP_KERNEL | __GFP_ACCOUNT); + event =kmalloc (alloc_len,GFP_KERNEL_ACCOUNT );memalloc_unuse_memcg ();if (unlikely (!event)) {
Signature · 1 line
2.18.0.399.gad0ab374a1-goog
Re: [PATCH] fs-fsnotify-account-fsnotify-metadata-to-kmemcg.patch.cleanup
Quoted 2 lines · Shakeel Butt
Hi Andres, this is a small cleanup to the patch "fs: fsnotify: account
*Andrew*
Quoted 37 lines
fsnotify metadata to kmemcg". Please squash.
Signed-off-by Shakeel Butt <[email protected]>--- fs/notify/fanotify/fanotify.c | 2 +- fs/notify/inotify/inotify_fsnotify.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)fs/notify/fanotify/fanotify.c +1
-1@@ -142,7 +142,7 @@ struct fanotify_event_info *fanotify_alloc_event(struct fsnotify_group *group, const struct path *path) {struct fanotify_event_info *event =NULL ; -gfp_t gfp =GFP_KERNEL | __GFP_ACCOUNT; +gfp_t gfp =GFP_KERNEL_ACCOUNT ;/* * For queues with unlimited length lost events are not expected and fs/notify/inotify/inotify_fsnotify.c +1
-2@@ -101,7 +101,7 @@ int inotify_handle_event(struct fsnotify_group *group,/* Whoever is interested in the event, pays for the allocation. */ memalloc_use_memcg (group->memcg); - event =kmalloc (alloc_len,GFP_KERNEL | __GFP_ACCOUNT); + event =kmalloc (alloc_len,GFP_KERNEL_ACCOUNT );memalloc_unuse_memcg ();if (unlikely (!event)) { --2.18.0.399.gad0ab374a1-goog
PATCH v8 2/2 fs, mm: account buffer_head to kmemcg
In reply to Shakeel ButtThe buffer_head can consume a significant amount of system memory and is directly related to the amount of page cache. In our production environment we have observed that a lot of machines are spending a significant amount of memory as buffer_head and can not be left as system memory overhead.
Charging buffer_head is not as simple as adding __GFP_ACCOUNT to the allocation. The buffer_heads can be allocated in a memcg different from the memcg of the page for which buffer_heads are being allocated. One concrete example is memory reclaim. The reclaim can trigger I/O of pages of any memcg on the system. So, the right way to charge buffer_head is to extract the memcg from the page for which buffer_heads are being allocated and then use targeted memcg charging API.
---
Changelog since v2:
- get_mem_cgroup_from_page() returns root_mem_cgroup if page->memcg is either NULL or css_tryget_online fails.
Changelog since v1:
- simple code cleanups
fs/buffer.c | 10 +++++++++- include/linux/memcontrol.h | 7 +++++++ mm/memcontrol.c | 22 ++++++++++++++++++++++ 3 files changed, 38 insertions(+), 1 deletion(-)
fs/buffer.c +9 -1
@@ -45,6 +45,7 @@#include <linux/mpage.h> #include <linux/bit_spinlock.h> #include <linux/pagevec.h> +#include <linux/sched/mm.h> #include <trace/events/block.h> static int fsync_buffers_list (spinlock_t *lock,struct list_head *list);
@@ -815,10 +816,14 @@ struct buffer_head *alloc_page_buffers(struct page *page, unsigned long size,struct buffer_head *bh, *head;gfp_t gfp =GFP_NOFS ;long offset; +struct mem_cgroup *memcg;if (retry) gfp |= __GFP_NOFAIL; + memcg =get_mem_cgroup_from_page (page); +memalloc_use_memcg (memcg); + head =NULL ; offset =PAGE_SIZE ;while ((offset -= size) >=0 ) {
@@ -835,6 +840,9 @@ struct buffer_head *alloc_page_buffers(struct page *page, unsigned long size,/* Link the buffer to its page */ set_bh_page (bh, page, offset); } +out: +memalloc_unuse_memcg (); +mem_cgroup_put (memcg);return head;/* * In case anything failed, we just free everything we got.
@@ -848,7 +856,7 @@ struct buffer_head *alloc_page_buffers(struct page *page, unsigned long size, }while (head); } -return NULL ; + goto out; }EXPORT_SYMBOL_GPL (alloc_page_buffers);
include/linux/memcontrol.h +7 -0
@@ -380,6 +380,8 @@ struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p);struct mem_cgroup *get_mem_cgroup_from_mm (struct mm_struct *mm); +struct mem_cgroup *get_mem_cgroup_from_page (struct page *page); +static inline struct mem_cgroup *mem_cgroup_from_css (struct cgroup_subsys_state *css){ return css ? container_of(css, struct mem_cgroup, css) : NULL;
@@ -865,6 +867,11 @@ static inline struct mem_cgroup *get_mem_cgroup_from_mm(struct mm_struct *mm)return NULL ; } +static inline struct mem_cgroup *get_mem_cgroup_from_page (struct page *page) +{ +return NULL ; +} +static inline void mem_cgroup_put (struct mem_cgroup *memcg) { }
mm/memcontrol.c +22 -0
@@ -713,6 +713,28 @@ struct mem_cgroup *get_mem_cgroup_from_mm(struct mm_struct *mm) }EXPORT_SYMBOL (get_mem_cgroup_from_mm); +/** +* get_mem_cgroup_from_page: Obtain a reference on given page's memcg. +* @page: page from which memcg should be extracted. +* +* Obtain a reference on page->memcg and returns it if successful. Otherwise +* root_mem_cgroup is returned. +*/ +struct mem_cgroup *get_mem_cgroup_from_page (struct page *page) +{ +struct mem_cgroup *memcg = page->mem_cgroup; + +if (mem_cgroup_disabled ()) +return NULL ; + +rcu_read_lock (); +if (!memcg || !css_tryget_online (&memcg->css)) + memcg = root_mem_cgroup; +rcu_read_unlock (); +return memcg; +} +EXPORT_SYMBOL (get_mem_cgroup_from_page); +/** * If current->active_memcg is non-NULL, do not fallback to current->mm->memcg. */
Signature · 1 line
2.18.0.rc2.346.g013aa6912e-goog
PATCH 1/1 fs-mm-account-buffer_head-to-kmemcg.patch.fix
The patch "fs, mm: account buffer_head to kmemcg" missed to add __GFP_ACCOUNT flag into the gfp mask for directed memcg charging. So, adding it. Andrew, please squash this into the original patch.
--- fs/buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/buffer.c +1 -1
@@ -814,7 +814,7 @@ struct buffer_head *alloc_page_buffers(struct page *page, unsigned long size, bool retry) {struct buffer_head *bh, *head; -gfp_t gfp =GFP_NOFS ; +gfp_t gfp =GFP_NOFS | __GFP_ACCOUNT;long offset;struct mem_cgroup *memcg;
Signature · 1 line
2.18.0.399.gad0ab374a1-goog
Andrew Morton
maintainerQuoted 19 lines · On Wed, 27 Jun 2018 12:12:48 -0700 Shakeel Butt <[email protected]> wrote:
The Linux kernel's memory cgroup allows limiting the memory usage of the jobs running on the system to provide isolation between the jobs. All the kernel memory allocated in the context of the job and marked with
__GFP_ACCOUNTwill also be included in the memory usage and be limited by the job's limit.The kernel memory can only be charged to the memcg of the process in whose context kernel memory was allocated. However there are cases where the allocated kernel memory should be charged to the memcg different from the current processes's memcg. This patch series contains two such concrete use-cases i.e. fsnotify and
buffer_head.The fsnotify event objects can consume a lot of system memory for large or unlimited queues if there is either no or slow listener. The events are allocated in the context of the event producer. However they should be charged to the event consumer. Similarly the
buffer_headobjects can be allocated in a memcg different from the memcg of the page for whichbuffer_headobjects are being allocated.
Quoted 6 lines
To solve this issue, this patch series introduces mechanism to charge kernel memory to a given memcg. In case of fsnotify events, the memcg of the consumer can be used for charging and for
buffer_head, the memcg of the page can be charged. For directed charging, the caller can use the scope API memalloc_[un]use_memcg() to specify the memcg to charge for all the__GFP_ACCOUNTallocations within the scope.
This patchset is not showing signs of having been well reviewed at this time. Could people please take another look?
Quoted 28 lines · Andrew Morton
Quoted 19 lines · On Wed, 27 Jun 2018 12:12:48 -0700 Shakeel Butt <[email protected]> wrote:
The Linux kernel's memory cgroup allows limiting the memory usage of the jobs running on the system to provide isolation between the jobs. All the kernel memory allocated in the context of the job and marked with
__GFP_ACCOUNTwill also be included in the memory usage and be limited by the job's limit.The kernel memory can only be charged to the memcg of the process in whose context kernel memory was allocated. However there are cases where the allocated kernel memory should be charged to the memcg different from the current processes's memcg. This patch series contains two such concrete use-cases i.e. fsnotify and
buffer_head.The fsnotify event objects can consume a lot of system memory for large or unlimited queues if there is either no or slow listener. The events are allocated in the context of the event producer. However they should be charged to the event consumer. Similarly the
buffer_headobjects can be allocated in a memcg different from the memcg of the page for whichbuffer_headobjects are being allocated.Quoted 6 lines
To solve this issue, this patch series introduces mechanism to charge kernel memory to a given memcg. In case of fsnotify events, the memcg of the consumer can be used for charging and for
buffer_head, the memcg of the page can be charged. For directed charging, the caller can use the scope API memalloc_[un]use_memcg() to specify the memcg to charge for all the__GFP_ACCOUNTallocations within the scope.
Quoted 2 lines
This patchset is not showing signs of having been well reviewed at this time. Could people please take another look?
I don't have the mailing list archives for this anymore, but the series as it stands in mmots looks good to me and incorporates all the feedback I remember giving.
[ My only gripe really is that it applies current->active_memcg only
to kmem charges, not others as well. Right now it doesn't matter, but I can see this costing a kernel developer implementing remote charges for something other than kmem some time to realize. ]
Anyway, please feel free to add
for 1/2 and 2/2 plus their two fixlets.