From: Oleg Nesterov <oleg@redhat.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>,
Tejun Heo <tj@kernel.org>,
Vladimir Davydov <vdavydov@parallels.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 3/3] memcg: get rid of mm_struct::owner
Date: Tue, 26 May 2015 18:36:46 +0200 [thread overview]
Message-ID: <20150526163646.GA29968@redhat.com> (raw)
In-Reply-To: <1432641006-8025-4-git-send-email-mhocko@suse.cz>
On 05/26, Michal Hocko wrote:
>
> @@ -426,17 +426,7 @@ struct mm_struct {
> struct kioctx_table __rcu *ioctx_table;
> #endif
> #ifdef CONFIG_MEMCG
> - /*
> - * "owner" points to a task that is regarded as the canonical
> - * user/owner of this mm. All of the following must be true in
> - * order for it to be changed:
> - *
> - * current == mm->owner
> - * current->mm != mm
> - * new_owner->mm == mm
> - * new_owner->alloc_lock is held
> - */
> - struct task_struct __rcu *owner;
> + struct mem_cgroup __rcu *memcg;
Yes, thanks, this is what I tried to suggest ;)
But I can't review this series. Simply because I know nothing about
memcs. I don't even know how to use it.
Just one question,
> +static struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p)
> +{
> + if (!p->mm)
> + return NULL;
> + return rcu_dereference(p->mm->memcg);
> +}
Probably I missed something, but it seems that the callers do not
expect it can return NULL. Perhaps sock_update_memcg() is fine, but
task_in_mem_cgroup() calls it when find_lock_task_mm() fails, and in
this case ->mm is NULL.
And in fact I can't understand what mem_cgroup_from_task() actually
means, with or without these changes.
And another question. I can't understand what happens when a task
execs... IOW, could you confirm that exec_mmap() does not need
mm_set_memcg(mm, oldmm->memcg) ?
Oleg.
--
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: Oleg Nesterov <oleg@redhat.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>,
Tejun Heo <tj@kernel.org>,
Vladimir Davydov <vdavydov@parallels.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 3/3] memcg: get rid of mm_struct::owner
Date: Tue, 26 May 2015 18:36:46 +0200 [thread overview]
Message-ID: <20150526163646.GA29968@redhat.com> (raw)
In-Reply-To: <1432641006-8025-4-git-send-email-mhocko@suse.cz>
On 05/26, Michal Hocko wrote:
>
> @@ -426,17 +426,7 @@ struct mm_struct {
> struct kioctx_table __rcu *ioctx_table;
> #endif
> #ifdef CONFIG_MEMCG
> - /*
> - * "owner" points to a task that is regarded as the canonical
> - * user/owner of this mm. All of the following must be true in
> - * order for it to be changed:
> - *
> - * current == mm->owner
> - * current->mm != mm
> - * new_owner->mm == mm
> - * new_owner->alloc_lock is held
> - */
> - struct task_struct __rcu *owner;
> + struct mem_cgroup __rcu *memcg;
Yes, thanks, this is what I tried to suggest ;)
But I can't review this series. Simply because I know nothing about
memcs. I don't even know how to use it.
Just one question,
> +static struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p)
> +{
> + if (!p->mm)
> + return NULL;
> + return rcu_dereference(p->mm->memcg);
> +}
Probably I missed something, but it seems that the callers do not
expect it can return NULL. Perhaps sock_update_memcg() is fine, but
task_in_mem_cgroup() calls it when find_lock_task_mm() fails, and in
this case ->mm is NULL.
And in fact I can't understand what mem_cgroup_from_task() actually
means, with or without these changes.
And another question. I can't understand what happens when a task
execs... IOW, could you confirm that exec_mmap() does not need
mm_set_memcg(mm, oldmm->memcg) ?
Oleg.
next prev parent reply other threads:[~2015-05-26 16:37 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-26 11:50 [RFC 0/3] get rid of mm_struct::owner Michal Hocko
2015-05-26 11:50 ` Michal Hocko
2015-05-26 11:50 ` [RFC 1/3] memcg: restructure mem_cgroup_can_attach() Michal Hocko
2015-05-26 11:50 ` Michal Hocko
2015-05-26 11:50 ` [RFC 2/3] memcg: Use mc.moving_task as the indication for charge moving Michal Hocko
2015-05-26 11:50 ` Michal Hocko
2015-05-26 11:50 ` [RFC 3/3] memcg: get rid of mm_struct::owner Michal Hocko
2015-05-26 11:50 ` Michal Hocko
2015-05-26 14:10 ` Johannes Weiner
2015-05-26 14:10 ` Johannes Weiner
2015-05-26 15:11 ` Michal Hocko
2015-05-26 15:11 ` Michal Hocko
2015-05-26 17:20 ` Johannes Weiner
2015-05-26 17:20 ` Johannes Weiner
2015-05-27 14:48 ` Michal Hocko
2015-05-27 14:48 ` Michal Hocko
2015-05-28 21:07 ` Tejun Heo
2015-05-28 21:07 ` Tejun Heo
2015-05-29 12:08 ` Michal Hocko
2015-05-29 12:08 ` Michal Hocko
2015-05-29 13:10 ` Tejun Heo
2015-05-29 13:10 ` Tejun Heo
2015-05-29 13:45 ` Michal Hocko
2015-05-29 13:45 ` Michal Hocko
2015-05-29 14:07 ` Tejun Heo
2015-05-29 14:07 ` Tejun Heo
2015-05-29 14:57 ` Michal Hocko
2015-05-29 14:57 ` Michal Hocko
2015-05-29 15:23 ` Tejun Heo
2015-05-29 15:23 ` Tejun Heo
2015-05-29 15:26 ` Michal Hocko
2015-05-29 15:26 ` Michal Hocko
2015-05-26 16:36 ` Oleg Nesterov [this message]
2015-05-26 16:36 ` Oleg Nesterov
2015-05-26 17:22 ` Michal Hocko
2015-05-26 17:22 ` Michal Hocko
2015-05-26 17:38 ` Oleg Nesterov
2015-05-26 17:38 ` Oleg Nesterov
2015-05-27 9:43 ` Michal Hocko
2015-05-27 9:43 ` 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=20150526163646.GA29968@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=tj@kernel.org \
--cc=vdavydov@parallels.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.