Files
android_kernel_xiaomi_sm8450/include/linux
Tejun Heo 01fb58bcba slab: remove synchronous synchronize_sched() from memcg cache deactivation path
With kmem cgroup support enabled, kmem_caches can be created and
destroyed frequently and a great number of near empty kmem_caches can
accumulate if there are a lot of transient cgroups and the system is not
under memory pressure.  When memory reclaim starts under such
conditions, it can lead to consecutive deactivation and destruction of
many kmem_caches, easily hundreds of thousands on moderately large
systems, exposing scalability issues in the current slab management
code.  This is one of the patches to address the issue.

slub uses synchronize_sched() to deactivate a memcg cache.
synchronize_sched() is an expensive and slow operation and doesn't scale
when a huge number of caches are destroyed back-to-back.  While there
used to be a simple batching mechanism, the batching was too restricted
to be helpful.

This patch implements slab_deactivate_memcg_cache_rcu_sched() which slub
can use to schedule sched RCU callback instead of performing
synchronize_sched() synchronously while holding cgroup_mutex.  While
this adds online cpus, mems and slab_mutex operations, operating on
these locks back-to-back from the same kworker, which is what's gonna
happen when there are many to deactivate, isn't expensive at all and
this gets rid of the scalability problem completely.

Link: http://lkml.kernel.org/r/20170117235411.9408-9-tj@kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Jay Vana <jsvana@fb.com>
Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 16:41:27 -08:00
..
2017-01-30 14:39:20 +01:00
2016-11-17 23:19:00 +01:00
2017-02-06 18:20:16 +02:00
2016-12-22 22:58:37 -05:00
2016-10-19 14:34:36 -04:00
2017-02-10 15:52:24 -05:00
2017-01-25 13:17:47 -05:00
2016-12-08 13:31:11 -05:00
2016-08-11 09:41:35 -06:00
2016-10-25 11:08:28 +08:00
2016-12-08 16:37:33 -08:00
2017-02-04 00:47:59 +01:00
2016-10-07 18:46:30 -07:00
2016-12-05 19:01:16 -05:00
2016-10-28 08:48:16 -06:00
2016-11-25 10:15:13 -08:00
2016-12-05 19:01:16 -05:00
2016-12-25 17:21:22 +01:00
2017-02-10 11:15:08 +01:00
2017-02-11 20:59:41 -05:00
2016-11-30 14:36:01 +11:00
2016-09-14 09:18:09 -06:00
2017-02-01 09:13:45 +01:00
2016-08-10 11:23:44 -04:00
2016-12-12 18:55:06 -08:00
2016-12-25 17:21:23 +01:00
2016-09-27 12:33:47 +02:00
2016-12-06 11:05:46 +01:00
2017-01-12 16:48:26 -05:00
2016-07-29 12:17:52 -07:00
2016-08-28 23:32:41 -04:00
2016-11-16 18:32:02 -05:00
2016-12-19 17:29:44 -05:00
2016-12-12 18:55:07 -08:00
2016-12-06 10:17:03 +02:00
2017-02-20 10:15:11 -05:00
2016-10-31 16:18:30 -04:00
2016-10-14 11:36:59 -07:00
2016-09-27 21:52:00 -04:00
2016-11-15 16:34:27 -08:00
2017-02-17 12:28:35 -05:00
2016-10-31 15:45:18 -07:00
2017-01-09 16:07:38 -05:00
2016-10-05 18:23:36 -04:00
2017-01-10 18:31:55 -08:00
2017-02-03 11:19:34 -05:00
2016-12-25 17:21:22 +01:00
2017-02-10 11:15:08 +01:00
2017-01-10 18:31:55 -08:00
2017-02-03 10:17:02 +01:00
2016-12-09 22:12:21 -05:00
2017-02-10 16:34:17 +00:00
2016-12-12 18:55:08 -08:00
2017-01-11 09:21:41 +01:00
2016-12-25 17:21:22 +01:00