From: Glauber Costa <glommer@parallels.com>
To: Suleiman Souhlal <suleiman@google.com>
Cc: cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, devel@openvz.org,
kamezawa.hiroyu@jp.fujitsu.com, Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Greg Thelen <gthelen@google.com>
Subject: Re: [PATCH 00/23] slab+slub accounting for memcg
Date: Wed, 2 May 2012 12:14:37 -0300 [thread overview]
Message-ID: <4FA14F5D.4040504@parallels.com> (raw)
In-Reply-To: <CABCjUKDGw20nojLqvZZbn0orO1aR9dhTZ65X_7ZSZto0eMk1GQ@mail.gmail.com>
On 04/30/2012 06:43 PM, Suleiman Souhlal wrote:
>> I am leaving destruction of caches out of the series, although most
>> > of the infrastructure for that is here, since we did it in earlier
>> > series. This is basically because right now Kame is reworking it for
>> > user memcg, and I like the new proposed behavior a lot more. We all seemed
>> > to have agreed that reclaim is an interesting problem by itself, and
>> > is not included in this already too complicated series. Please note
>> > that this is still marked as experimental, so we have so room. A proper
>> > shrinker implementation is a hard requirement to take the kmem controller
>> > out of the experimental state.
> We will have to be careful for cache destruction.
> I found several races between allocation and destruction, in my patchset.
>
> I think we should consider doing the uncharging of kmem when
> destroying a memcg in mem_cgroup_destroy() instead of in
> pre_destroy(), because it's still possible that there are threads in
> the cgroup while pre_destroy() is being called (or for threads to be
> moved into the cgroup).
I found some problems here as well.
I am trying to work ontop of what Kamezawa posted for pre_destroy()
rework. I have one or two incorrect uncharging issues to solve, that's
actually what is holding me for posting a new version.
expected soon
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: Suleiman Souhlal <suleiman@google.com>
Cc: <cgroups@vger.kernel.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, <devel@openvz.org>,
<kamezawa.hiroyu@jp.fujitsu.com>, Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Greg Thelen <gthelen@google.com>
Subject: Re: [PATCH 00/23] slab+slub accounting for memcg
Date: Wed, 2 May 2012 12:14:37 -0300 [thread overview]
Message-ID: <4FA14F5D.4040504@parallels.com> (raw)
In-Reply-To: <CABCjUKDGw20nojLqvZZbn0orO1aR9dhTZ65X_7ZSZto0eMk1GQ@mail.gmail.com>
On 04/30/2012 06:43 PM, Suleiman Souhlal wrote:
>> I am leaving destruction of caches out of the series, although most
>> > of the infrastructure for that is here, since we did it in earlier
>> > series. This is basically because right now Kame is reworking it for
>> > user memcg, and I like the new proposed behavior a lot more. We all seemed
>> > to have agreed that reclaim is an interesting problem by itself, and
>> > is not included in this already too complicated series. Please note
>> > that this is still marked as experimental, so we have so room. A proper
>> > shrinker implementation is a hard requirement to take the kmem controller
>> > out of the experimental state.
> We will have to be careful for cache destruction.
> I found several races between allocation and destruction, in my patchset.
>
> I think we should consider doing the uncharging of kmem when
> destroying a memcg in mem_cgroup_destroy() instead of in
> pre_destroy(), because it's still possible that there are threads in
> the cgroup while pre_destroy() is being called (or for threads to be
> moved into the cgroup).
I found some problems here as well.
I am trying to work ontop of what Kamezawa posted for pre_destroy()
rework. I have one or two incorrect uncharging issues to solve, that's
actually what is holding me for posting a new version.
expected soon
next prev parent reply other threads:[~2012-05-02 15:14 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-20 21:48 [PATCH 00/23] slab+slub accounting for memcg Glauber Costa
2012-04-20 21:48 ` Glauber Costa
2012-04-20 21:48 ` [PATCH 01/23] slub: don't create a copy of the name string in kmem_cache_create Glauber Costa
2012-04-20 21:48 ` Glauber Costa
2012-04-20 21:48 ` Glauber Costa
2012-04-20 21:48 ` [PATCH 02/23] slub: always get the cache from its page in kfree Glauber Costa
2012-04-20 21:48 ` Glauber Costa
2012-04-20 21:49 ` [PATCH 03/23] slab: rename gfpflags to allocflags Glauber Costa
2012-04-20 21:49 ` Glauber Costa
2012-04-20 21:49 ` Glauber Costa
2012-04-20 21:49 ` [PATCH 04/23] memcg: Make it possible to use the stock for more than one page Glauber Costa
2012-04-20 21:49 ` Glauber Costa
2012-04-20 21:49 ` [PATCH 05/23] memcg: Reclaim when more than one page needed Glauber Costa
2012-04-20 21:49 ` Glauber Costa
2012-04-20 21:49 ` [PATCH 06/23] slab: use obj_size field of struct kmem_cache when not debugging Glauber Costa
2012-04-20 21:49 ` Glauber Costa
2012-04-20 21:49 ` Glauber Costa
2012-04-20 21:49 ` [PATCH 07/23] change defines to an enum Glauber Costa
2012-04-20 21:49 ` Glauber Costa
2012-04-20 21:49 ` [PATCH 08/23] don't force return value checking in res_counter_charge_nofail Glauber Costa
2012-04-20 21:49 ` Glauber Costa
2012-04-20 22:01 ` [PATCH 00/23] slab+slub accounting for memcg Glauber Costa
2012-04-20 22:01 ` Glauber Costa
[not found] ` <1334958560-18076-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-30 21:43 ` Suleiman Souhlal
2012-04-30 21:43 ` Suleiman Souhlal
2012-04-30 21:43 ` Suleiman Souhlal
2012-05-02 15:14 ` Glauber Costa [this message]
2012-05-02 15:14 ` Glauber Costa
-- strict thread matches above, loose matches on Subject: below --
2012-04-20 21:57 Glauber Costa
2012-04-20 21:57 ` Glauber Costa
2012-04-20 21:57 ` Glauber Costa
[not found] ` <1334959051-18203-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-22 23:59 ` Glauber Costa
2012-04-22 23:59 ` Glauber Costa
2012-04-22 23:59 ` 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=4FA14F5D.4040504@parallels.com \
--to=glommer@parallels.com \
--cc=cgroups@vger.kernel.org \
--cc=devel@openvz.org \
--cc=fweisbec@gmail.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=suleiman@google.com \
/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.