From: Vladimir Davydov <vdavydov@parallels.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org, Michal Hocko <mhocko@suse.cz>,
Greg Thelen <gthelen@google.com>, Tejun Heo <tj@kernel.org>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 0/3] mm: memcontrol: eliminate charge reparenting
Date: Sun, 21 Sep 2014 19:50:43 +0400 [thread overview]
Message-ID: <20140921155043.GC32416@esperanza> (raw)
In-Reply-To: <1411243235-24680-1-git-send-email-hannes@cmpxchg.org>
Hi Johannes,
On Sat, Sep 20, 2014 at 04:00:32PM -0400, Johannes Weiner wrote:
> The decoupling of css from the user-visible cgroup, word-sized per-cpu
> css reference counters, and css iterators that include offlined groups
> means we can take per-charge css references, continue to reclaim from
> offlined groups, and so get rid of the error-prone charge reparenting.
I haven't reviewed this set yet, but I agree that zapping user memory
reparenting sounds like a sane idea, because reparenting won't let the
css go in most cases anyway due to swap and kmem charges.
However, I think we must reparent list_lru items, otherwise per-memcg
arrays (kmem_caches, list_lrus) will grow uncontrollably due to dead
css's, which is unacceptable. Note it isn't the same as the user memory
reparenting, because we don't need to reparent kmem_cache objects or
charges - they can stay where they are pinning the css till they are
freed, because the memcg_cache_id, which I want to free on offline, is
not used for kmem allocations/frees after css offline. Actually we only
need to empty the list_lru corresponding to the dead memory cgroup,
which is relatively easy to implement. This is what patch 13 of the "Per
memcg slab shrinkers" patch set, which I sent recently, does (see
https://lkml.org/lkml/2014/9/21/64).
What do you think about it?
Thanks,
Vladimir
--
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: Johannes Weiner <hannes@cmpxchg.org>
Cc: <linux-mm@kvack.org>, Michal Hocko <mhocko@suse.cz>,
Greg Thelen <gthelen@google.com>, Tejun Heo <tj@kernel.org>,
<cgroups@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [patch 0/3] mm: memcontrol: eliminate charge reparenting
Date: Sun, 21 Sep 2014 19:50:43 +0400 [thread overview]
Message-ID: <20140921155043.GC32416@esperanza> (raw)
In-Reply-To: <1411243235-24680-1-git-send-email-hannes@cmpxchg.org>
Hi Johannes,
On Sat, Sep 20, 2014 at 04:00:32PM -0400, Johannes Weiner wrote:
> The decoupling of css from the user-visible cgroup, word-sized per-cpu
> css reference counters, and css iterators that include offlined groups
> means we can take per-charge css references, continue to reclaim from
> offlined groups, and so get rid of the error-prone charge reparenting.
I haven't reviewed this set yet, but I agree that zapping user memory
reparenting sounds like a sane idea, because reparenting won't let the
css go in most cases anyway due to swap and kmem charges.
However, I think we must reparent list_lru items, otherwise per-memcg
arrays (kmem_caches, list_lrus) will grow uncontrollably due to dead
css's, which is unacceptable. Note it isn't the same as the user memory
reparenting, because we don't need to reparent kmem_cache objects or
charges - they can stay where they are pinning the css till they are
freed, because the memcg_cache_id, which I want to free on offline, is
not used for kmem allocations/frees after css offline. Actually we only
need to empty the list_lru corresponding to the dead memory cgroup,
which is relatively easy to implement. This is what patch 13 of the "Per
memcg slab shrinkers" patch set, which I sent recently, does (see
https://lkml.org/lkml/2014/9/21/64).
What do you think about it?
Thanks,
Vladimir
next prev parent reply other threads:[~2014-09-21 15:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-20 20:00 [patch 0/3] mm: memcontrol: eliminate charge reparenting Johannes Weiner
2014-09-20 20:00 ` Johannes Weiner
2014-09-20 20:00 ` [patch 1/3] mm: memcontrol: take a css reference for each charged page Johannes Weiner
2014-09-20 20:00 ` Johannes Weiner
2014-09-22 8:24 ` Vladimir Davydov
2014-09-22 8:24 ` Vladimir Davydov
[not found] ` <1411243235-24680-2-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2014-10-08 13:27 ` Michal Hocko
2014-10-08 13:27 ` Michal Hocko
2014-10-08 13:27 ` Michal Hocko
2014-10-08 13:29 ` Michal Hocko
2014-10-08 13:29 ` Michal Hocko
2014-09-20 20:00 ` [patch 2/3] mm: memcontrol: remove obsolete kmemcg pinning tricks Johannes Weiner
2014-09-20 20:00 ` Johannes Weiner
[not found] ` <1411243235-24680-3-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2014-09-22 8:25 ` Vladimir Davydov
2014-09-22 8:25 ` Vladimir Davydov
2014-09-22 8:25 ` Vladimir Davydov
2014-10-08 13:32 ` Michal Hocko
2014-10-08 13:32 ` Michal Hocko
2014-09-20 20:00 ` [patch 3/3] mm: memcontrol: continue cache reclaim from offlined groups Johannes Weiner
2014-09-20 20:00 ` Johannes Weiner
2014-09-22 8:32 ` Vladimir Davydov
2014-09-22 8:32 ` Vladimir Davydov
2014-10-08 14:03 ` Michal Hocko
2014-10-08 14:03 ` Michal Hocko
2014-09-21 15:50 ` Vladimir Davydov [this message]
2014-09-21 15:50 ` [patch 0/3] mm: memcontrol: eliminate charge reparenting Vladimir Davydov
[not found] ` <1411243235-24680-1-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2014-10-08 12:48 ` Michal Hocko
2014-10-08 12:48 ` Michal Hocko
2014-10-08 12:48 ` Michal Hocko
2014-10-08 14:17 ` Johannes Weiner
2014-10-08 14:17 ` Johannes Weiner
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=20140921155043.GC32416@esperanza \
--to=vdavydov@parallels.com \
--cc=cgroups@vger.kernel.org \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=tj@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.