Show slab memory usage on OOM and SysRq-M

The out_of_memory() function and SysRq-M handler call show_mem() to show the current memory usage state.

This is also helpful to see which slabs are the largest in the system.

mm/slab.c +17 -0

+static unsigned long get_cache_size(struct kmem_cache *cachep)
+{
+       unsigned long slabs;
+       struct kmem_list3 *l3;
+       struct list_head *lh;
+       int node;
+
+       slabs = 0;
+
+       for_each_online_node (node) {
+               l3 = cachep->nodelists[node];
+               if (l3 == NULL)
+                       continue;
+
+               spin_lock(&l3->list_lock);
+               list_for_each (lh, &l3->slabs_full)
+                       slabs++;

Hi,

Quoted 5 lines · Pavel Emelianov

The out_of_memory() function and SysRq-M handler call show_mem() to show the current memory usage state.

This is also helpful to see which slabs are the largest in the system.

Makes sense.

Quoted 4 lines

mm/slab.c +0 -0

index 21b3c61..9a5829a 100644

mm/slab.c static inline void init_lock_keys(void) · line 752

Quoted 5 lines

mm/slab.c +1 -0

@@ -749,6 +749,7 @@ static inline void init_lock_keys(void)
  * 2. Protect sanity of cpu_online_map against cpu hotplug events
  */
 static DEFINE_MUTEX(cache_chain_mutex);
+static DEFINE_SPINLOCK(cache_chain_lock);

So, now we have two locks protecting cache_chain? Please explain why you can't use the mutex.

Quoted 24 lines

mm/slab.c +24 -0

+static unsigned long get_cache_size(struct kmem_cache *cachep)
+{
+       unsigned long slabs;
+       struct kmem_list3 *l3;
+       struct list_head *lh;
+       int node;
+
+       slabs = 0;
+
+       for_each_online_node (node) {
+               l3 = cachep->nodelists[node];
+               if (l3 == NULL)
+                       continue;
+
+               spin_lock(&l3->list_lock);
+               list_for_each (lh, &l3->slabs_full)
+                       slabs++;
+               list_for_each (lh, &l3->slabs_partial)
+                       slabs++;
+               list_for_each (lh, &l3->slabs_free)
+                       slabs++;
+               spin_unlock(&l3->list_lock);
+       }
+

Quoted 4 lines

mm/slab.c +2 -0

+       return slabs * ((PAGE_SIZE << cachep->gfporder) +
+               (OFF_SLAB(cachep) ? cachep->slabp_cache->buffer_size :

0));
+}

Considering you're doing this at out_of_memory() time, wouldn't it make more sense to add a ->nr_pages to struct kmem_cache and do the tracking in kmem_getpages/kmem_freepages?

I would also drop the OFF_SLAB bits because it really doesn't matter that much for your purposes. Besides, you're already per-node and per-CPU caches here which attribute to much more memory on NUMA setups for example.

Quoted 2 lines

So, now we have two locks protecting cache_chain? Please explain why you can't use the mutex.

Because OOM can actually happen with this mutex locked. For example kmem_cache_create() locks it and calls kmalloc(), or write to /proc/slabinfo also locks it and calls do_tune_cpu_caches(). This is very rare case and the deadlock is VERY unlikely to happen, but it will be very disappointing if it happens.

Moreover, I put the call to show_slabs() into sysrq handler, so it may be called from atomic context.

Making mutex_trylock() is possible, but we risk of loosing this info in case OOM happens while the mutex is locked for cache shrinking (see cache_reap() for example)...

So we have a choice - either we have an additional lock on a slow and rare paths and show this info for sure, or we do not have a lock, but have a risk of loosing this info.

Quoted 4 lines

I would also drop the OFF_SLAB bits because it really doesn't matter that much for your purposes. Besides, you're already per-node and per-CPU caches here which attribute to much more memory on NUMA setups for example.

This gives us a more precise information :) The precision is less than 1% so if nobody likes/needs it, this may be dropped.

Hi Pavel,

Quoted 2 lines · At some point in time, I wrote:

Quoted 2 lines

So, now we have two locks protecting cache_chain? Please explain why you can't use the mutex.

Quoted 13 lines · Pavel Emelianov

Because OOM can actually happen with this mutex locked. For example kmem_cache_create() locks it and calls kmalloc(), or write to /proc/slabinfo also locks it and calls do_tune_cpu_caches(). This is very rare case and the deadlock is VERY unlikely to happen, but it will be very disappointing if it happens.

Moreover, I put the call to show_slabs() into sysrq handler, so it may be called from atomic context.

Making mutex_trylock() is possible, but we risk of loosing this info in case OOM happens while the mutex is locked for cache shrinking (see cache_reap() for example)...

Quoted 3 lines

So we have a choice - either we have an additional lock on a slow and rare paths and show this info for sure, or we do not have a lock, but have a risk of loosing this info.

I don't worry about performance as much I do about maintenance. Do you know if mutex_trylock() is a problem in practice? Could we perhaps fix

the worst offenders who are holding cache_chain_mutex for a long time?

In any case, if we do end up adding the lock, please add a BIG FAT COMMENT explaining why we have it.

Quoted 4 lines · At some point in time, I wrote:

Quoted 4 lines

I would also drop the OFF_SLAB bits because it really doesn't matter that much for your purposes. Besides, you're already per-node and per-CPU caches here which attribute to much more memory on NUMA setups for example.

Quoted 2 lines · Pavel Emelianov

This gives us a more precise information :) The precision is less than 1% so if nobody likes/needs it, this may be dropped.

My point is that the "precision" is useless here. We probably waste more memory in the caches which are not accounted here. So I'd just drop it.

Hi,

Quoted 23 lines · Pavel Emelianov

mm/slab.c +23 -0

+static unsigned long get_cache_size(struct kmem_cache *cachep)
+{
+       unsigned long slabs;
+       struct kmem_list3 *l3;
+       struct list_head *lh;
+       int node;
+
+       slabs = 0;
+
+       for_each_online_node (node) {
+               l3 = cachep->nodelists[node];
+               if (l3 == NULL)
+                       continue;
+
+               spin_lock(&l3->list_lock);
+               list_for_each (lh, &l3->slabs_full)
+                       slabs++;
+               list_for_each (lh, &l3->slabs_partial)
+                       slabs++;
+               list_for_each (lh, &l3->slabs_free)
+                       slabs++;
+               spin_unlock(&l3->list_lock);
+       }

mm/slab.c const struct seq_operations slabstats_op · line 4581

Quoted 4 lines

mm/slab.c +4 -0

+
+       return slabs * ((PAGE_SIZE << cachep->gfporder) +
+               (OFF_SLAB(cachep) ? cachep->slabp_cache->buffer_size : 0));
+}

Considering you're doing this at out_of_memory() time, wouldn't it make more sense to add a ->nr_pages to struct kmem_cache and do the tracking in kmem_getpages/kmem_freepages?

This nr_pages should be in struct kmem_list3, not in struct kmem_cache, or else you defeat NUMA optimizations if touching a field in kmem_cache at kmem_getpages()/kmem_freepages() time.

Quoted 3 lines · Eric Dumazet

This nr_pages should be in struct kmem_list3, not in struct kmem_cache, or else you defeat NUMA optimizations if touching a field in kmem_cache at kmem_getpages()/kmem_freepages() time.

We already touch ->flags, ->gfpflags, and ->gfporder in kmem_getpages(). Sorry for my ignorance, but how is this different?