On Wed, Jan 28, 2015 at 01:57:52PM -0800, Andrew Morton wrote: > On Wed, 28 Jan 2015 19:22:49 +0300 Vladimir Davydov <vdavy...@parallels.com> > 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
