All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Cc: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
	Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
	KAMEZAWA Hiroyuki
	<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
Subject: Re: [PATCH -v2] memcg: don't do cleanup manually if mem_cgroup_css_online() fails
Date: Wed, 3 Apr 2013 16:37:53 +0800	[thread overview]
Message-ID: <515BEA61.9080100@huawei.com> (raw)
In-Reply-To: <20130403081843.GC14384-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>

>>> But memcg_update_cache_sizes calls memcg_kmem_clear_activated on the
>>> error path.
>>>
>>
>> But memcg_kmem_mark_dead() checks the ACCOUNT flag not the ACCOUNTED flag.
>> Am I missing something?
>>
> 
> Dang. You are right! Glauber, is there any reason why
> memcg_kmem_mark_dead checks only KMEM_ACCOUNTED_ACTIVE rather than
> KMEM_ACCOUNTED_MASK?
> 
> This all is very confusing to say the least.
> 
> Anyway, this all means that Li's first patch is correct. I am not sure I
> like it though. I think that the refcount cleanup should be done as
> close to where it has been taken as possible otherwise we will end up in
> this "chase the nasty details" again and again. There are definitely two
> bugs here. The one introduced by e4715f01 and the other one introduced
> even earlier (I haven't checked that history yet). I think we should do
> something like the 2 follow up patches but if you guys think that the smaller
> patch from Li is more appropriate then I will not block it.
> 

Or we can queue my patch for 3.9, and then see if we want to change the
tear down process, and if yes we make the change for 3.10.

WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Glauber Costa <glommer@parallels.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Cgroups <cgroups@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH -v2] memcg: don't do cleanup manually if mem_cgroup_css_online() fails
Date: Wed, 3 Apr 2013 16:37:53 +0800	[thread overview]
Message-ID: <515BEA61.9080100@huawei.com> (raw)
In-Reply-To: <20130403081843.GC14384@dhcp22.suse.cz>

>>> But memcg_update_cache_sizes calls memcg_kmem_clear_activated on the
>>> error path.
>>>
>>
>> But memcg_kmem_mark_dead() checks the ACCOUNT flag not the ACCOUNTED flag.
>> Am I missing something?
>>
> 
> Dang. You are right! Glauber, is there any reason why
> memcg_kmem_mark_dead checks only KMEM_ACCOUNTED_ACTIVE rather than
> KMEM_ACCOUNTED_MASK?
> 
> This all is very confusing to say the least.
> 
> Anyway, this all means that Li's first patch is correct. I am not sure I
> like it though. I think that the refcount cleanup should be done as
> close to where it has been taken as possible otherwise we will end up in
> this "chase the nasty details" again and again. There are definitely two
> bugs here. The one introduced by e4715f01 and the other one introduced
> even earlier (I haven't checked that history yet). I think we should do
> something like the 2 follow up patches but if you guys think that the smaller
> patch from Li is more appropriate then I will not block it.
> 

Or we can queue my patch for 3.9, and then see if we want to change the
tear down process, and if yes we make the change for 3.10.

--
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: Li Zefan <lizefan@huawei.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Glauber Costa <glommer@parallels.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Cgroups <cgroups@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH -v2] memcg: don't do cleanup manually if mem_cgroup_css_online() fails
Date: Wed, 3 Apr 2013 16:37:53 +0800	[thread overview]
Message-ID: <515BEA61.9080100@huawei.com> (raw)
In-Reply-To: <20130403081843.GC14384@dhcp22.suse.cz>

>>> But memcg_update_cache_sizes calls memcg_kmem_clear_activated on the
>>> error path.
>>>
>>
>> But memcg_kmem_mark_dead() checks the ACCOUNT flag not the ACCOUNTED flag.
>> Am I missing something?
>>
> 
> Dang. You are right! Glauber, is there any reason why
> memcg_kmem_mark_dead checks only KMEM_ACCOUNTED_ACTIVE rather than
> KMEM_ACCOUNTED_MASK?
> 
> This all is very confusing to say the least.
> 
> Anyway, this all means that Li's first patch is correct. I am not sure I
> like it though. I think that the refcount cleanup should be done as
> close to where it has been taken as possible otherwise we will end up in
> this "chase the nasty details" again and again. There are definitely two
> bugs here. The one introduced by e4715f01 and the other one introduced
> even earlier (I haven't checked that history yet). I think we should do
> something like the 2 follow up patches but if you guys think that the smaller
> patch from Li is more appropriate then I will not block it.
> 

Or we can queue my patch for 3.9, and then see if we want to change the
tear down process, and if yes we make the change for 3.10.


  parent reply	other threads:[~2013-04-03  8:37 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-02  7:35 [PATCH] memcg: don't do cleanup manually if mem_cgroup_css_online() fails Li Zefan
2013-04-02  7:35 ` Li Zefan
2013-04-02  8:03 ` Li Zefan
2013-04-02  8:03   ` Li Zefan
2013-04-02  8:03   ` Li Zefan
2013-04-02  8:07   ` Glauber Costa
2013-04-02  8:07     ` Glauber Costa
2013-04-02  8:34     ` Li Zefan
2013-04-02  8:34       ` Li Zefan
2013-04-02  8:42       ` Glauber Costa
2013-04-02  8:42         ` Glauber Costa
2013-04-02  8:43 ` Glauber Costa
2013-04-02  8:43   ` Glauber Costa
     [not found] ` <515A8A40.6020406-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-02 12:16   ` Michal Hocko
2013-04-02 12:16     ` Michal Hocko
2013-04-02 12:16     ` Michal Hocko
2013-04-02 12:22     ` Glauber Costa
2013-04-02 12:22       ` Glauber Costa
     [not found]       ` <515ACD7F.3070009-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-04-02 13:32         ` Michal Hocko
2013-04-02 13:32           ` Michal Hocko
2013-04-02 13:32           ` Michal Hocko
2013-04-02 13:36           ` Glauber Costa
2013-04-02 13:36             ` Glauber Costa
     [not found]           ` <20130402133227.GM24345-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-03  3:43             ` Li Zefan
2013-04-03  3:43               ` Li Zefan
2013-04-03  3:43               ` Li Zefan
2013-04-02 14:16     ` Michal Hocko
2013-04-02 14:16       ` Michal Hocko
     [not found]       ` <20130402141646.GQ24345-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-02 14:20         ` Glauber Costa
2013-04-02 14:20           ` Glauber Costa
2013-04-02 14:20           ` Glauber Costa
2013-04-02 14:28           ` Michal Hocko
2013-04-02 14:28             ` Michal Hocko
     [not found]             ` <20130402142825.GA32520-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-02 14:33               ` Glauber Costa
2013-04-02 14:33                 ` Glauber Costa
2013-04-02 14:33                 ` Glauber Costa
     [not found]                 ` <515AEC3A.2030401-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-04-02 15:04                   ` [PATCH -v2] " Michal Hocko
2013-04-02 15:04                     ` Michal Hocko
2013-04-02 15:04                     ` Michal Hocko
     [not found]                     ` <20130402150422.GB32520-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-03  3:49                       ` Li Zefan
2013-04-03  3:49                         ` Li Zefan
2013-04-03  3:49                         ` Li Zefan
     [not found]                         ` <515BA6C9.2000704-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-03  7:43                           ` Michal Hocko
2013-04-03  7:43                             ` Michal Hocko
2013-04-03  7:43                             ` Michal Hocko
2013-04-03  7:49                             ` Li Zefan
2013-04-03  7:49                               ` Li Zefan
2013-04-03  8:18                               ` Michal Hocko
2013-04-03  8:18                                 ` Michal Hocko
2013-04-03  8:30                                 ` Glauber Costa
2013-04-03  8:30                                   ` Glauber Costa
2013-04-03  8:30                                   ` Glauber Costa
     [not found]                                 ` <20130403081843.GC14384-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-03  8:37                                   ` Li Zefan [this message]
2013-04-03  8:37                                     ` Li Zefan
2013-04-03  8:37                                     ` Li Zefan
2013-04-03  8:50                                     ` Michal Hocko
2013-04-03  8:50                                       ` Michal Hocko
2013-04-03  8:53                                       ` [PATCH 1/2] Revert "memcg: avoid dangling reference count in creation failure." Michal Hocko
2013-04-03  8:53                                         ` Michal Hocko
2013-04-03  8:53                                         ` [PATCH 2/2] memcg, kmem: clean up reference count handling on the error path Michal Hocko
2013-04-03  8:53                                           ` Michal Hocko
     [not found]                                           ` <1364979234-16427-2-git-send-email-mhocko-AlSwsSmVLrQ@public.gmane.org>
2013-04-03  9:48                                             ` Michal Hocko
2013-04-03  9:48                                               ` Michal Hocko
2013-04-03  9:48                                               ` Michal Hocko
2013-04-03  8:08                     ` [PATCH -v2] memcg: don't do cleanup manually if mem_cgroup_css_online() fails Glauber Costa
2013-04-03  8:08                       ` Glauber Costa

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=515BEA61.9080100@huawei.com \
    --to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
    --cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
    --cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=mhocko-AlSwsSmVLrQ@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.