From: Ying Han <yinghan@google.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Glauber Costa <glommer@parallels.com>, Tejun Heo <tj@kernel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
kamezawa.hiroyuki@gmail.com
Subject: Re: [RFC][PATCH 9/9 v2] memcg: never return error at pre_destroy()
Date: Fri, 27 Apr 2012 14:28:31 -0700 [thread overview]
Message-ID: <CALWz4iyiM-CFgVaHiE1Lgd1ZwJzHwY3tx9XX6HeDPUV_wVPAtQ@mail.gmail.com> (raw)
In-Reply-To: <4F9A375D.7@jp.fujitsu.com>
On Thu, Apr 26, 2012 at 11:06 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> When force_empty() called by ->pre_destroy(), no memory reclaim happens
> and it doesn't take very long time which requires signal_pending() check.
> And if we return -EINTR from pre_destroy(), cgroup.c show warning.
>
> This patch removes signal check in force_empty(). By this, ->pre_destroy()
> returns success always.
>
> Note: check for 'cgroup is empty' remains for force_empty interface.
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
> mm/hugetlb.c | 10 +---------
> mm/memcontrol.c | 14 +++++---------
> 2 files changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 4dd6b39..770f1642 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1922,20 +1922,12 @@ int hugetlb_force_memcg_empty(struct cgroup *cgroup)
> int ret = 0, idx = 0;
>
> do {
> + /* see memcontrol.c::mem_cgroup_force_empty() */
> if (cgroup_task_count(cgroup)
> || !list_empty(&cgroup->children)) {
> ret = -EBUSY;
> goto out;
> }
> - /*
> - * If the task doing the cgroup_rmdir got a signal
> - * we don't really need to loop till the hugetlb resource
> - * usage become zero.
> - */
> - if (signal_pending(current)) {
> - ret = -EINTR;
> - goto out;
> - }
> for_each_hstate(h) {
> spin_lock(&hugetlb_lock);
> list_for_each_entry(page, &h->hugepage_activelist, lru) {
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 2715223..ee350c5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3852,8 +3852,6 @@ static int mem_cgroup_force_empty_list(struct mem_cgroup *memcg,
> pc = lookup_page_cgroup(page);
>
> ret = mem_cgroup_move_parent(page, pc, memcg, GFP_KERNEL);
> - if (ret == -ENOMEM || ret == -EINTR)
> - break;
>
> if (ret == -EBUSY || ret == -EINVAL) {
> /* found lock contention or "pc" is obsolete. */
> @@ -3863,7 +3861,7 @@ static int mem_cgroup_force_empty_list(struct mem_cgroup *memcg,
> busy = NULL;
> }
>
> - if (!ret && !list_empty(list))
> + if (!loop)
This looks a bit strange to me... why we make the change ?
--Ying
> return -EBUSY;
> return ret;
> }
> @@ -3893,11 +3891,12 @@ static int mem_cgroup_force_empty(struct mem_cgroup *memcg, bool free_all)
> move_account:
> do {
> ret = -EBUSY;
> + /*
> + * This never happens when this is called by ->pre_destroy().
> + * But we need to take care of force_empty interface.
> + */
> if (cgroup_task_count(cgrp) || !list_empty(&cgrp->children))
> goto out;
> - ret = -EINTR;
> - if (signal_pending(current))
> - goto out;
> /* This is for making all *used* pages to be on LRU. */
> lru_add_drain_all();
> drain_all_stock_sync(memcg);
> @@ -3918,9 +3917,6 @@ move_account:
> }
> mem_cgroup_end_move(memcg);
> memcg_oom_recover(memcg);
> - /* it seems parent cgroup doesn't have enough mem */
> - if (ret == -ENOMEM)
> - goto try_to_free;
> cond_resched();
> /* "ret" should also be checked to ensure all lists are empty. */
> } while (res_counter_read_u64(&memcg->res, RES_USAGE) > 0 || ret);
> --
> 1.7.4.1
>
>
--
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>
next prev parent reply other threads:[~2012-04-27 21:28 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 5:45 [RFC][PATCH 0/7 v2] memcg: prevent failure in pre_destroy() KAMEZAWA Hiroyuki
2012-04-27 5:49 ` [RFC][PATCH 1/7 v2] temporal compile-fix in linux-next KAMEZAWA Hiroyuki
2012-04-30 8:47 ` Aneesh Kumar K.V
2012-04-27 5:51 ` [RFC][PATCH 2/7 v2] memcg: fix error code in hugetlb_force_memcg_empty() KAMEZAWA Hiroyuki
2012-04-30 8:49 ` Aneesh Kumar K.V
2012-04-27 5:53 ` [RFC][PATCH 3/7 v2] res_counter: add res_counter_uncharge_until() KAMEZAWA Hiroyuki
2012-04-27 17:08 ` Glauber Costa
2012-04-27 23:51 ` Hiroyuki Kamezawa
2012-04-27 18:18 ` Tejun Heo
2012-04-27 23:51 ` Hiroyuki Kamezawa
2012-04-27 5:54 ` [RFC][PATCH 4/7 v2] memcg: use res_counter_uncharge_until in move_parent KAMEZAWA Hiroyuki
2012-04-27 17:16 ` Glauber Costa
2012-04-27 18:26 ` Ying Han
2012-04-27 20:11 ` Glauber Costa
2012-04-27 23:58 ` Hiroyuki Kamezawa
2012-04-27 18:20 ` Tejun Heo
2012-04-27 23:59 ` Hiroyuki Kamezawa
2012-04-30 9:00 ` Aneesh Kumar K.V
2012-04-27 5:58 ` [RFC][PATCH 5/9 v2] move charges to root at rmdir if use_hierarchy is unset KAMEZAWA Hiroyuki
2012-04-27 19:12 ` Ying Han
2012-04-28 0:01 ` Hiroyuki Kamezawa
2012-04-30 9:07 ` Aneesh Kumar K.V
2012-04-27 6:00 ` [RFC][PATCH 6/9 v2] memcg: don't uncharge in mem_cgroup_move_account KAMEZAWA Hiroyuki
2012-04-27 6:02 ` [RFC][PATCH 7/9 v2] cgroup: avoid attaching task to a cgroup under rmdir() KAMEZAWA Hiroyuki
2012-04-27 10:39 ` Frederic Weisbecker
2012-04-28 0:06 ` Hiroyuki Kamezawa
2012-04-27 20:31 ` Tejun Heo
2012-04-27 20:33 ` Tejun Heo
2012-04-27 6:04 ` [RFC][PATCH 8/9 v2] cgroup: avoid creating new cgroup under a cgroup being destroyed KAMEZAWA Hiroyuki
2012-04-27 17:18 ` Glauber Costa
2012-04-27 20:40 ` Tejun Heo
2012-04-27 20:41 ` Tejun Heo
2012-04-28 0:20 ` Hiroyuki Kamezawa
2012-04-28 2:00 ` Tejun Heo
2012-04-28 9:31 ` Hiroyuki Kamezawa
2012-04-28 21:31 ` Tejun Heo
2012-04-27 6:06 ` [RFC][PATCH 9/9 v2] memcg: never return error at pre_destroy() KAMEZAWA Hiroyuki
2012-04-27 21:28 ` Ying Han [this message]
2012-04-28 0:25 ` Hiroyuki Kamezawa
2012-04-30 17:02 ` Ying Han
2012-05-01 22:28 ` Suleiman Souhlal
2012-05-02 3:34 ` Hiroyuki Kamezawa
2012-04-27 18:16 ` [RFC][PATCH 0/7 v2] memcg: prevent failure in pre_destroy() Tejun Heo
2012-04-27 23:48 ` Hiroyuki Kamezawa
2012-04-28 16:13 ` Michal Hocko
2012-04-29 6:03 ` Michal Hocko
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=CALWz4iyiM-CFgVaHiE1Lgd1ZwJzHwY3tx9XX6HeDPUV_wVPAtQ@mail.gmail.com \
--to=yinghan@google.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=cgroups@vger.kernel.org \
--cc=fweisbec@gmail.com \
--cc=glommer@parallels.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kamezawa.hiroyuki@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox