Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1365744

Re: [PATCH 01/11] mm/slab: hold a slab_mutex when calling __kmem_cache_shrink()

From Christoph Lameter <cl@linux.com>
Newsgroups linux.kernel
Subject Re: [PATCH 01/11] mm/slab: hold a slab_mutex when calling __kmem_cache_shrink()
Date 2016-03-29 03:00 +0200
Message-ID <rhQaK-6GM-3@gated-at.bofh.it> (permalink)
References <rhxUt-2rs-3@gated-at.bofh.it> <rhxUt-2rs-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, 28 Mar 2016, js1304@gmail.com wrote:

> Major kmem_cache metadata in slab subsystem is synchronized with
> the slab_mutex. In SLAB, if some of them is changed, node's shared
> array cache would be freed and re-populated. If __kmem_cache_shrink()
> is called at the same time, it will call drain_array() with n->shared
> without holding node lock so problem can happen.
>
> We can fix this small theoretical race condition by holding node lock
> in drain_array(), but, holding a slab_mutex in kmem_cache_shrink()
> looks more appropriate solution because stable state would make things
> less error-prone and this is not performance critical path.

Ummm.. The mutex taking is added to common code. So this will also affect
SLUB.  The patch needs to consider this. Do we want to force all
allocators to run shrinking only when holding the lock? SLUB does not
need to hold the mutex. And frankly the mutex is for reconfiguration of
metadata which is *not* occurring here. A shrink operation does not do
that. Can we figure out a slab specific way of handling synchronization
in the strange free/realloc cycle?

It seems that taking the node lock is the appropriate level of
synchrnonization since the concern is with the contents of a shared cache
at that level. There is no change of metadata which would require the
mutex.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 01/11] mm/slab: hold a slab_mutex when calling __kmem_cache_shrink() js1304@gmail.com - 2016-03-28 07:30 +0200
  Re: [PATCH 01/11] mm/slab: hold a slab_mutex when calling  __kmem_cache_shrink() Christoph Lameter <cl@linux.com> - 2016-03-29 03:00 +0200
    Re: [PATCH 01/11] mm/slab: hold a slab_mutex when calling  __kmem_cache_shrink() Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-30 10:20 +0200
  Re: [PATCH 01/11] mm/slab: hold a slab_mutex when calling  __kmem_cache_shrink() Nikolay Borisov <kernel@kyup.com> - 2016-03-31 13:00 +0200
    Re: [PATCH 01/11] mm/slab: hold a slab_mutex when calling  __kmem_cache_shrink() Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-04-01 04:20 +0200

csiph-web