On Wed, Jan 28, 2015 at 01:57:52PM -0800, Andrew Morton wrote: > On Wed, 28 Jan 2015 19:22:49 +0300 Vladimir Davydov <vdavydov@xxxxxxxxxxxxx> wrote: > > @@ -3375,51 +3376,56 @@ int __kmem_cache_shrink(struct kmem_cache *s) > > struct kmem_cache_node *n; > > struct page *page; > > struct page *t; > > - int objects = oo_objects(s->max); > > - struct list_head *slabs_by_inuse = > > - kmalloc(sizeof(struct list_head) * objects, GFP_KERNEL); > > + LIST_HEAD(discard); > > + struct list_head promote[SHRINK_PROMOTE_MAX]; > > 512 bytes of stack. The call paths leading to __kmem_cache_shrink() > are many and twisty. How do we know this isn't a problem? Because currently __kmem_cache_shrink is only called just from a couple of places, each of which isn't supposed to have a great stack depth AFAIU, namely: - slab_mem_going_offline_callback - MEM_GOING_OFFLINE handler - shrink_store - invoked upon write to /sys/kernel/slab/cache/shrink - acpi_os_purge_cache - only called on acpi init - memcg_deactivate_kmem_caches - called from cgroup_destroy_wq > The logic behind choosing "32" sounds rather rubbery. What goes wrong > if we use, say, "4"? We could, but kmem_cache_shrink would cope with fragmentation less efficiently. Come to think of it, do we really need to optimize slab placement in kmem_cache_shrink? None of its users except shrink_store expects it - they just want to purge the cache before destruction, that's it. May be, we'd better move slab placement optimization to a separate SLUB's private function that would be called only by shrink_store, where we can put up with kmalloc failures? Christoph, what do you think? Thanks, Vladimir -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>