From: Vladimir Davydov <vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Glauber Costa <glommer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>,
Pekka Enberg <penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Subject: Re: [PATCH 1/6] slab: cleanup kmem_cache_create_memcg()
Date: Thu, 19 Dec 2013 12:51:38 +0400 [thread overview]
Message-ID: <52B2B39A.7070303@parallels.com> (raw)
In-Reply-To: <20131219084447.GA9331-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On 12/19/2013 12:44 PM, Michal Hocko wrote:
> On Thu 19-12-13 10:31:43, Vladimir Davydov wrote:
>> On 12/18/2013 08:56 PM, Michal Hocko wrote:
>>> On Wed 18-12-13 17:16:52, Vladimir Davydov wrote:
>>>> Signed-off-by: Vladimir Davydov <vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>>>> Cc: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
>>>> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
>>>> Cc: Glauber Costa <glommer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Cc: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
>>>> Cc: Pekka Enberg <penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>> Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
>>> Dunno, is this really better to be worth the code churn?
>>>
>>> It even makes the generated code tiny bit bigger:
>>> text data bss dec hex filename
>>> 4355 171 236 4762 129a mm/slab_common.o.after
>>> 4342 171 236 4749 128d mm/slab_common.o.before
>>>
>>> Or does it make the further changes much more easier? Be explicit in the
>>> patch description if so.
>> Hi, Michal
>>
>> IMO, undoing under labels looks better than inside conditionals, because
>> we don't have to repeat the same deinitialization code then, like this
>> (note three calls to kmem_cache_free()):
> Agreed but the resulting code is far from doing nice undo on different
> conditions. You have out_free_cache which frees everything regardless
> whether name or cache registration failed. So it doesn't help with
> readability much IMO.
AFAIK it's common practice not to split kfree's to be called under
different labels on fail paths, because kfree(NULL) results in a no-op.
Since on undo, we only call kfree, I introduce the only label. Of course
I could do something like
s->name=...
if (!s->name)
goto out_free_name;
err = __kmem_new_cache(...)
if (err)
goto out_free_name;
<...>
out_free_name:
kfree(s->name);
out_free_cache:
kfree(s);
goto out_unlock;
But I think using only out_free_cache makes the code look clearer.
>
>> s = kmem_cache_zalloc(kmem_cache, GFP_KERNEL);
>> if (s) {
>> s->object_size = s->size = size;
>> s->align = calculate_alignment(flags, align, size);
>> s->ctor = ctor;
>>
>> if (memcg_register_cache(memcg, s, parent_cache)) {
>> kmem_cache_free(kmem_cache, s);
>> err = -ENOMEM;
>> goto out_locked;
>> }
>>
>> s->name = kstrdup(name, GFP_KERNEL);
>> if (!s->name) {
>> kmem_cache_free(kmem_cache, s);
>> err = -ENOMEM;
>> goto out_locked;
>> }
>>
>> err = __kmem_cache_create(s, flags);
>> if (!err) {
>> s->refcount = 1;
>> list_add(&s->list, &slab_caches);
>> memcg_cache_list_add(memcg, s);
>> } else {
>> kfree(s->name);
>> kmem_cache_free(kmem_cache, s);
>> }
>> } else
>> err = -ENOMEM;
>>
>> The next patch, which fixes the memcg_params leakage on error, would
>> make it even worse introducing two calls to memcg_free_cache_params()
>> after kstrdup and __kmem_cache_create.
>>
>> If you think it isn't worthwhile applying this patch, just let me know,
>> I don't mind dropping it.
> As I've said if it helps with the later patches then I do not mind but
> on its own it doesn't sound like a huge improvement.
>
> Btw. you do not have to set err = -ENOMEM before goto out_locked. Just
> set before kmem_cache_zalloc. You also do not need to initialize it to 0
> because kmem_cache_sanity_check will set it.
OK, thanks.
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 1/6] slab: cleanup kmem_cache_create_memcg()
Date: Thu, 19 Dec 2013 12:51:38 +0400 [thread overview]
Message-ID: <52B2B39A.7070303@parallels.com> (raw)
In-Reply-To: <20131219084447.GA9331@dhcp22.suse.cz>
On 12/19/2013 12:44 PM, Michal Hocko wrote:
> On Thu 19-12-13 10:31:43, Vladimir Davydov wrote:
>> On 12/18/2013 08:56 PM, Michal Hocko wrote:
>>> On Wed 18-12-13 17:16:52, Vladimir Davydov wrote:
>>>> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
>>>> Cc: Michal Hocko <mhocko@suse.cz>
>>>> Cc: Johannes Weiner <hannes@cmpxchg.org>
>>>> Cc: Glauber Costa <glommer@gmail.com>
>>>> Cc: Christoph Lameter <cl@linux.com>
>>>> Cc: Pekka Enberg <penberg@kernel.org>
>>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>> Dunno, is this really better to be worth the code churn?
>>>
>>> It even makes the generated code tiny bit bigger:
>>> text data bss dec hex filename
>>> 4355 171 236 4762 129a mm/slab_common.o.after
>>> 4342 171 236 4749 128d mm/slab_common.o.before
>>>
>>> Or does it make the further changes much more easier? Be explicit in the
>>> patch description if so.
>> Hi, Michal
>>
>> IMO, undoing under labels looks better than inside conditionals, because
>> we don't have to repeat the same deinitialization code then, like this
>> (note three calls to kmem_cache_free()):
> Agreed but the resulting code is far from doing nice undo on different
> conditions. You have out_free_cache which frees everything regardless
> whether name or cache registration failed. So it doesn't help with
> readability much IMO.
AFAIK it's common practice not to split kfree's to be called under
different labels on fail paths, because kfree(NULL) results in a no-op.
Since on undo, we only call kfree, I introduce the only label. Of course
I could do something like
s->name=...
if (!s->name)
goto out_free_name;
err = __kmem_new_cache(...)
if (err)
goto out_free_name;
<...>
out_free_name:
kfree(s->name);
out_free_cache:
kfree(s);
goto out_unlock;
But I think using only out_free_cache makes the code look clearer.
>
>> s = kmem_cache_zalloc(kmem_cache, GFP_KERNEL);
>> if (s) {
>> s->object_size = s->size = size;
>> s->align = calculate_alignment(flags, align, size);
>> s->ctor = ctor;
>>
>> if (memcg_register_cache(memcg, s, parent_cache)) {
>> kmem_cache_free(kmem_cache, s);
>> err = -ENOMEM;
>> goto out_locked;
>> }
>>
>> s->name = kstrdup(name, GFP_KERNEL);
>> if (!s->name) {
>> kmem_cache_free(kmem_cache, s);
>> err = -ENOMEM;
>> goto out_locked;
>> }
>>
>> err = __kmem_cache_create(s, flags);
>> if (!err) {
>> s->refcount = 1;
>> list_add(&s->list, &slab_caches);
>> memcg_cache_list_add(memcg, s);
>> } else {
>> kfree(s->name);
>> kmem_cache_free(kmem_cache, s);
>> }
>> } else
>> err = -ENOMEM;
>>
>> The next patch, which fixes the memcg_params leakage on error, would
>> make it even worse introducing two calls to memcg_free_cache_params()
>> after kstrdup and __kmem_cache_create.
>>
>> If you think it isn't worthwhile applying this patch, just let me know,
>> I don't mind dropping it.
> As I've said if it helps with the later patches then I do not mind but
> on its own it doesn't sound like a huge improvement.
>
> Btw. you do not have to set err = -ENOMEM before goto out_locked. Just
> set before kmem_cache_zalloc. You also do not need to initialize it to 0
> because kmem_cache_sanity_check will set it.
OK, 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 1/6] slab: cleanup kmem_cache_create_memcg()
Date: Thu, 19 Dec 2013 12:51:38 +0400 [thread overview]
Message-ID: <52B2B39A.7070303@parallels.com> (raw)
In-Reply-To: <20131219084447.GA9331@dhcp22.suse.cz>
On 12/19/2013 12:44 PM, Michal Hocko wrote:
> On Thu 19-12-13 10:31:43, Vladimir Davydov wrote:
>> On 12/18/2013 08:56 PM, Michal Hocko wrote:
>>> On Wed 18-12-13 17:16:52, Vladimir Davydov wrote:
>>>> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
>>>> Cc: Michal Hocko <mhocko@suse.cz>
>>>> Cc: Johannes Weiner <hannes@cmpxchg.org>
>>>> Cc: Glauber Costa <glommer@gmail.com>
>>>> Cc: Christoph Lameter <cl@linux.com>
>>>> Cc: Pekka Enberg <penberg@kernel.org>
>>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>> Dunno, is this really better to be worth the code churn?
>>>
>>> It even makes the generated code tiny bit bigger:
>>> text data bss dec hex filename
>>> 4355 171 236 4762 129a mm/slab_common.o.after
>>> 4342 171 236 4749 128d mm/slab_common.o.before
>>>
>>> Or does it make the further changes much more easier? Be explicit in the
>>> patch description if so.
>> Hi, Michal
>>
>> IMO, undoing under labels looks better than inside conditionals, because
>> we don't have to repeat the same deinitialization code then, like this
>> (note three calls to kmem_cache_free()):
> Agreed but the resulting code is far from doing nice undo on different
> conditions. You have out_free_cache which frees everything regardless
> whether name or cache registration failed. So it doesn't help with
> readability much IMO.
AFAIK it's common practice not to split kfree's to be called under
different labels on fail paths, because kfree(NULL) results in a no-op.
Since on undo, we only call kfree, I introduce the only label. Of course
I could do something like
s->name=...
if (!s->name)
goto out_free_name;
err = __kmem_new_cache(...)
if (err)
goto out_free_name;
<...>
out_free_name:
kfree(s->name);
out_free_cache:
kfree(s);
goto out_unlock;
But I think using only out_free_cache makes the code look clearer.
>
>> s = kmem_cache_zalloc(kmem_cache, GFP_KERNEL);
>> if (s) {
>> s->object_size = s->size = size;
>> s->align = calculate_alignment(flags, align, size);
>> s->ctor = ctor;
>>
>> if (memcg_register_cache(memcg, s, parent_cache)) {
>> kmem_cache_free(kmem_cache, s);
>> err = -ENOMEM;
>> goto out_locked;
>> }
>>
>> s->name = kstrdup(name, GFP_KERNEL);
>> if (!s->name) {
>> kmem_cache_free(kmem_cache, s);
>> err = -ENOMEM;
>> goto out_locked;
>> }
>>
>> err = __kmem_cache_create(s, flags);
>> if (!err) {
>> s->refcount = 1;
>> list_add(&s->list, &slab_caches);
>> memcg_cache_list_add(memcg, s);
>> } else {
>> kfree(s->name);
>> kmem_cache_free(kmem_cache, s);
>> }
>> } else
>> err = -ENOMEM;
>>
>> The next patch, which fixes the memcg_params leakage on error, would
>> make it even worse introducing two calls to memcg_free_cache_params()
>> after kstrdup and __kmem_cache_create.
>>
>> If you think it isn't worthwhile applying this patch, just let me know,
>> I don't mind dropping it.
> As I've said if it helps with the later patches then I do not mind but
> on its own it doesn't sound like a huge improvement.
>
> Btw. you do not have to set err = -ENOMEM before goto out_locked. Just
> set before kmem_cache_zalloc. You also do not need to initialize it to 0
> because kmem_cache_sanity_check will set it.
OK, thanks.
next prev parent reply other threads:[~2013-12-19 8:51 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
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 [this message]
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=52B2B39A.7070303@parallels.com \
--to=vdavydov-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org \
--cc=devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=glommer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
--cc=penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.