All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov@parallels.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	cgroups@vger.kernel.org, devel@openvz.org,
	Johannes Weiner <hannes@cmpxchg.org>,
	Glauber Costa <glommer@gmail.com>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 3/6] memcg, slab: cleanup barrier usage when accessing memcg_caches
Date: Thu, 19 Dec 2013 13:16:01 +0400	[thread overview]
Message-ID: <52B2B951.5080809@parallels.com> (raw)
In-Reply-To: <20131219091007.GC9331@dhcp22.suse.cz>

On 12/19/2013 01:10 PM, Michal Hocko wrote:
> On Thu 19-12-13 10:37:27, Vladimir Davydov wrote:
>> On 12/18/2013 09:14 PM, Michal Hocko wrote:
>>> On Wed 18-12-13 17:16:54, Vladimir Davydov wrote:
>>>> First, in memcg_create_kmem_cache() we should issue the write barrier
>>>> after the kmem_cache is initialized, but before storing the pointer to
>>>> it in its parent's memcg_params.
>>>>
>>>> Second, we should always issue the read barrier after
>>>> cache_from_memcg_idx() to conform with the write barrier.
>>>>
>>>> Third, its better to use smp_* versions of barriers, because we don't
>>>> need them on UP systems.
>>> Please be (much) more verbose on Why. Barriers are tricky and should be
>>> documented accordingly. So if you say that we should issue a barrier
>>> always be specific why we should do it.
>> In short, we have kmem_cache::memcg_params::memcg_caches is an array of
>> pointers to per-memcg caches. We access it lock-free so we should use
>> memory barriers during initialization. Obviously we should place a write
>> barrier just before we set the pointer in order to make sure nobody will
>> see a partially initialized structure. Besides there must be a read
>> barrier between reading the pointer and accessing the structure, to
>> conform with the write barrier. It's all that similar to rcu_assign and
>> rcu_deref. Currently the barrier usage looks rather strange:
>>
>> memcg_create_kmem_cache:
>>     initialize kmem
>>     set the pointer in memcg_caches
>>     wmb() // ???
>>
>> __memcg_kmem_get_cache:
>>     <...>
>>     read_barrier_depends() // ???
>>     cachep = root_cache->memcg_params->memcg_caches[memcg_id]
>>     <...>
> Why do we need explicit memory barriers when we can use RCU?
> __memcg_kmem_get_cache already dereferences within rcu_read_lock.

Because it's not RCU, IMO. RCU implies freeing the old version after a
grace period, while kmem_caches are freed immediately. We simply want to
be sure the kmem_cache is fully initialized. And we do not require
calling this in an RCU critical section.

> Btw. cache_from_memcg_idx is desperately asking for a comment about
> required locking.

Actually, I placed a reference to the comment there ;-) but no problem,
I move it to cache_from_memcg_idx().

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Davydov <vdavydov@parallels.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	<cgroups@vger.kernel.org>, <devel@openvz.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Glauber Costa <glommer@gmail.com>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 3/6] memcg, slab: cleanup barrier usage when accessing memcg_caches
Date: Thu, 19 Dec 2013 13:16:01 +0400	[thread overview]
Message-ID: <52B2B951.5080809@parallels.com> (raw)
In-Reply-To: <20131219091007.GC9331@dhcp22.suse.cz>

On 12/19/2013 01:10 PM, Michal Hocko wrote:
> On Thu 19-12-13 10:37:27, Vladimir Davydov wrote:
>> On 12/18/2013 09:14 PM, Michal Hocko wrote:
>>> On Wed 18-12-13 17:16:54, Vladimir Davydov wrote:
>>>> First, in memcg_create_kmem_cache() we should issue the write barrier
>>>> after the kmem_cache is initialized, but before storing the pointer to
>>>> it in its parent's memcg_params.
>>>>
>>>> Second, we should always issue the read barrier after
>>>> cache_from_memcg_idx() to conform with the write barrier.
>>>>
>>>> Third, its better to use smp_* versions of barriers, because we don't
>>>> need them on UP systems.
>>> Please be (much) more verbose on Why. Barriers are tricky and should be
>>> documented accordingly. So if you say that we should issue a barrier
>>> always be specific why we should do it.
>> In short, we have kmem_cache::memcg_params::memcg_caches is an array of
>> pointers to per-memcg caches. We access it lock-free so we should use
>> memory barriers during initialization. Obviously we should place a write
>> barrier just before we set the pointer in order to make sure nobody will
>> see a partially initialized structure. Besides there must be a read
>> barrier between reading the pointer and accessing the structure, to
>> conform with the write barrier. It's all that similar to rcu_assign and
>> rcu_deref. Currently the barrier usage looks rather strange:
>>
>> memcg_create_kmem_cache:
>>     initialize kmem
>>     set the pointer in memcg_caches
>>     wmb() // ???
>>
>> __memcg_kmem_get_cache:
>>     <...>
>>     read_barrier_depends() // ???
>>     cachep = root_cache->memcg_params->memcg_caches[memcg_id]
>>     <...>
> Why do we need explicit memory barriers when we can use RCU?
> __memcg_kmem_get_cache already dereferences within rcu_read_lock.

Because it's not RCU, IMO. RCU implies freeing the old version after a
grace period, while kmem_caches are freed immediately. We simply want to
be sure the kmem_cache is fully initialized. And we do not require
calling this in an RCU critical section.

> Btw. cache_from_memcg_idx is desperately asking for a comment about
> required locking.

Actually, I placed a reference to the comment there ;-) but no problem,
I move it to cache_from_memcg_idx().

Thanks.

  reply	other threads:[~2013-12-19  9:16 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-18 13:16 [PATCH 1/6] slab: cleanup kmem_cache_create_memcg() Vladimir Davydov
2013-12-18 13:16 ` Vladimir Davydov
2013-12-18 13:16 ` Vladimir Davydov
2013-12-18 13:16 ` [PATCH 2/6] memcg, slab: kmem_cache_create_memcg(): free memcg params on error Vladimir Davydov
2013-12-18 13:16   ` Vladimir Davydov
     [not found]   ` <9420ad797a2cfa14c23ad1ba6db615a2a51ffee0.1387372122.git.vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-18 17:06     ` Michal Hocko
2013-12-18 17:06       ` Michal Hocko
2013-12-18 17:06       ` Michal Hocko
     [not found]       ` <20131218170649.GC31080-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19  6:32         ` Vladimir Davydov
2013-12-19  6:32           ` Vladimir Davydov
2013-12-19  6:32           ` Vladimir Davydov
2013-12-19  8:48           ` Michal Hocko
2013-12-19  8:48             ` Michal Hocko
2013-12-19  9:01             ` Vladimir Davydov
2013-12-19  9:01               ` Vladimir Davydov
2013-12-19  9:19               ` Michal Hocko
2013-12-19  9:19                 ` Michal Hocko
2013-12-18 13:16 ` [PATCH 3/6] memcg, slab: cleanup barrier usage when accessing memcg_caches Vladimir Davydov
2013-12-18 13:16   ` Vladimir Davydov
2013-12-18 17:14   ` Michal Hocko
2013-12-18 17:14     ` Michal Hocko
2013-12-19  6:37     ` Vladimir Davydov
2013-12-19  6:37       ` Vladimir Davydov
2013-12-19  9:10       ` Michal Hocko
2013-12-19  9:10         ` Michal Hocko
2013-12-19  9:16         ` Vladimir Davydov [this message]
2013-12-19  9:16           ` Vladimir Davydov
2013-12-19  9:21           ` Michal Hocko
2013-12-19  9:21             ` Michal Hocko
     [not found]             ` <20131219092137.GG9331-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19  9:29               ` Vladimir Davydov
2013-12-19  9:29                 ` Vladimir Davydov
2013-12-19  9:29                 ` Vladimir Davydov
2013-12-19  9:36                 ` Michal Hocko
2013-12-19  9:36                   ` Michal Hocko
     [not found]                   ` <20131219093619.GA10855-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19  9:53                     ` Vladimir Davydov
2013-12-19  9:53                       ` Vladimir Davydov
2013-12-19  9:53                       ` Vladimir Davydov
2013-12-18 13:16 ` [PATCH 4/6] memcg, slab: check and init memcg_cahes under slab_mutex Vladimir Davydov
2013-12-18 13:16   ` Vladimir Davydov
2013-12-18 17:41   ` Michal Hocko
2013-12-18 17:41     ` Michal Hocko
     [not found]     ` <20131218174105.GE31080-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19  7:07       ` Vladimir Davydov
2013-12-19  7:07         ` Vladimir Davydov
2013-12-19  7:07         ` Vladimir Davydov
     [not found]         ` <52B29B2F.7050909-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-19  8:00           ` Glauber Costa
2013-12-19  8:00             ` Glauber Costa
2013-12-19  8:00             ` Glauber Costa
2013-12-19  9:12             ` Michal Hocko
2013-12-19  9:12               ` Michal Hocko
2013-12-19  9:17               ` Vladimir Davydov
2013-12-19  9:17                 ` Vladimir Davydov
2013-12-19  9:21             ` Vladimir Davydov
2013-12-19  9:21               ` Vladimir Davydov
2013-12-18 13:16 ` [PATCH 5/6] memcg: clear memcg_params after removing cache from memcg_slab_caches list Vladimir Davydov
2013-12-18 13:16   ` Vladimir Davydov
2013-12-18 13:16 ` [PATCH 6/6] memcg, slab: RCU protect memcg_params for root caches Vladimir Davydov
2013-12-18 13:16   ` Vladimir Davydov
2013-12-19  9:28   ` Michal Hocko
2013-12-19  9:28     ` Michal Hocko
2013-12-19  9:36     ` Vladimir Davydov
2013-12-19  9:36       ` Vladimir Davydov
     [not found]       ` <52B2BE2A.2080509-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-19  9:43         ` Michal Hocko
2013-12-19  9:43           ` Michal Hocko
2013-12-19  9:43           ` Michal Hocko
     [not found]           ` <20131219094333.GB10855-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19  9:47             ` Vladimir Davydov
2013-12-19  9:47               ` Vladimir Davydov
2013-12-19  9:47               ` Vladimir Davydov
2013-12-19 10:06               ` Michal Hocko
2013-12-19 10:06                 ` Michal Hocko
2013-12-18 16:56 ` [PATCH 1/6] slab: cleanup kmem_cache_create_memcg() Michal Hocko
2013-12-18 16:56   ` Michal Hocko
     [not found]   ` <20131218165603.GB31080-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19  6:31     ` Vladimir Davydov
2013-12-19  6:31       ` Vladimir Davydov
2013-12-19  6:31       ` Vladimir Davydov
2013-12-19  8:44       ` Michal Hocko
2013-12-19  8:44         ` Michal Hocko
     [not found]         ` <20131219084447.GA9331-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19  8:51           ` Vladimir Davydov
2013-12-19  8:51             ` Vladimir Davydov
2013-12-19  8:51             ` Vladimir Davydov
2013-12-19  9:16             ` Michal Hocko
2013-12-19  9:16               ` Michal Hocko
     [not found] ` <6f02b2d079ffd0990ae335339c803337b13ecd8c.1387372122.git.vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-19  7:27   ` Pekka Enberg
2013-12-19  7:27     ` Pekka Enberg
2013-12-19  7:27     ` Pekka Enberg
2013-12-19  8:17 ` [Devel] " Vasily Averin
2013-12-19  8:17   ` Vasily Averin
     [not found]   ` <52B2AB7C.1010803-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-19  8:39     ` Vladimir Davydov
2013-12-19  8:39       ` Vladimir Davydov
2013-12-19  8:39       ` Vladimir Davydov
     [not found]       ` <52B2B0A4.8050009-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-19  9:26         ` Vasily Averin
2013-12-19  9:26           ` Vasily Averin
2013-12-19  9:26           ` Vasily Averin
2013-12-19  9:42           ` Vladimir Davydov
2013-12-19  9:42             ` Vladimir Davydov
2013-12-19  9:45           ` Michal Hocko
2013-12-19  9:45             ` Michal Hocko
2013-12-19 10:23           ` Pekka Enberg
2013-12-19 10:23             ` Pekka Enberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52B2B951.5080809@parallels.com \
    --to=vdavydov@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=cl@linux.com \
    --cc=devel@openvz.org \
    --cc=glommer@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=penberg@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.