On Fri 29-05-15 11:23:28, Tejun Heo wrote:
> Hello,
>
> On Fri, May 29, 2015 at 04:57:39PM +0200, Michal Hocko wrote:
[...]
> > OK so you creat a task A (leader) which clones several tasks Pn with
> > CLONE_VM without CLONE_THREAD. Moving A around would control memcg
> > membership while Pn could
Hello,
On Fri, May 29, 2015 at 04:57:39PM +0200, Michal Hocko wrote:
> > > "
> > > It also allows several control groups that are virtually grouped by
> > > mm_struct, to exist independent of the memory controller i.e., without
> > > adding mem_cgroup's for each controller, to mm_struct.
> > > "
On Fri 29-05-15 10:07:37, Tejun Heo wrote:
> Hello,
>
> On Fri, May 29, 2015 at 03:45:53PM +0200, Michal Hocko wrote:
> > Sure but we are talking about processes here. They just happen to share
> > mm. And this is exactly the behavior change I am talking about... With
>
> Are we talking about
Hello,
On Fri, May 29, 2015 at 03:45:53PM +0200, Michal Hocko wrote:
> Sure but we are talking about processes here. They just happen to share
> mm. And this is exactly the behavior change I am talking about... With
Are we talking about CLONE_VM w/o CLONE_THREAD? ie. two threadgroups
sharing
On Fri 29-05-15 09:10:55, Tejun Heo wrote:
> On Fri, May 29, 2015 at 02:08:38PM +0200, Michal Hocko wrote:
> > > I suppose that making mm always follow the threadgroup leader should
> > > be fine, right?
> >
> > That is the plan.
>
> Cool.
>
> > > While this wouldn't make any difference in the
On Fri, May 29, 2015 at 02:08:38PM +0200, Michal Hocko wrote:
> > I suppose that making mm always follow the threadgroup leader should
> > be fine, right?
>
> That is the plan.
Cool.
> > While this wouldn't make any difference in the unified hierarchy,
>
> Just to make sure I understand.
On Thu 28-05-15 17:07:42, Tejun Heo wrote:
> Hello, Johannes, Michal.
>
> On Tue, May 26, 2015 at 10:10:11AM -0400, Johannes Weiner wrote:
> > On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
> > > Please note that this patch introduces a USER VISIBLE CHANGE OF BEHAVIOR.
> > >
On Thu 28-05-15 17:07:42, Tejun Heo wrote:
Hello, Johannes, Michal.
On Tue, May 26, 2015 at 10:10:11AM -0400, Johannes Weiner wrote:
On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
Please note that this patch introduces a USER VISIBLE CHANGE OF BEHAVIOR.
Without mm-owner
On Fri, May 29, 2015 at 02:08:38PM +0200, Michal Hocko wrote:
I suppose that making mm always follow the threadgroup leader should
be fine, right?
That is the plan.
Cool.
While this wouldn't make any difference in the unified hierarchy,
Just to make sure I understand. wouldn't make
On Fri 29-05-15 09:10:55, Tejun Heo wrote:
On Fri, May 29, 2015 at 02:08:38PM +0200, Michal Hocko wrote:
I suppose that making mm always follow the threadgroup leader should
be fine, right?
That is the plan.
Cool.
While this wouldn't make any difference in the unified
Hello,
On Fri, May 29, 2015 at 03:45:53PM +0200, Michal Hocko wrote:
Sure but we are talking about processes here. They just happen to share
mm. And this is exactly the behavior change I am talking about... With
Are we talking about CLONE_VM w/o CLONE_THREAD? ie. two threadgroups
sharing the
Hello,
On Fri, May 29, 2015 at 04:57:39PM +0200, Michal Hocko wrote:
It also allows several control groups that are virtually grouped by
mm_struct, to exist independent of the memory controller i.e., without
adding mem_cgroup's for each controller, to mm_struct.
suggests it
On Fri 29-05-15 10:07:37, Tejun Heo wrote:
Hello,
On Fri, May 29, 2015 at 03:45:53PM +0200, Michal Hocko wrote:
Sure but we are talking about processes here. They just happen to share
mm. And this is exactly the behavior change I am talking about... With
Are we talking about CLONE_VM
On Fri 29-05-15 11:23:28, Tejun Heo wrote:
Hello,
On Fri, May 29, 2015 at 04:57:39PM +0200, Michal Hocko wrote:
[...]
OK so you creat a task A (leader) which clones several tasks Pn with
CLONE_VM without CLONE_THREAD. Moving A around would control memcg
membership while Pn could be moved
Hello, Johannes, Michal.
On Tue, May 26, 2015 at 10:10:11AM -0400, Johannes Weiner wrote:
> On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
> > Please note that this patch introduces a USER VISIBLE CHANGE OF BEHAVIOR.
> > Without mm->owner _all_ tasks associated with the mm_struct
Hello, Johannes, Michal.
On Tue, May 26, 2015 at 10:10:11AM -0400, Johannes Weiner wrote:
On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
Please note that this patch introduces a USER VISIBLE CHANGE OF BEHAVIOR.
Without mm-owner _all_ tasks associated with the mm_struct would
On Tue 26-05-15 13:20:19, Johannes Weiner wrote:
> On Tue, May 26, 2015 at 05:11:49PM +0200, Michal Hocko wrote:
> > On Tue 26-05-15 10:10:11, Johannes Weiner wrote:
> > > On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
> > > > @@ -104,7 +105,12 @@ static inline bool
On Tue 26-05-15 19:38:22, Oleg Nesterov wrote:
> On 05/26, Michal Hocko wrote:
> >
> > On Tue 26-05-15 18:36:46, Oleg Nesterov wrote:
> > >
> > > > +static struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p)
> > > > +{
> > > > + if (!p->mm)
> > > > + return NULL;
> >
On Tue 26-05-15 19:38:22, Oleg Nesterov wrote:
On 05/26, Michal Hocko wrote:
On Tue 26-05-15 18:36:46, Oleg Nesterov wrote:
+static struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p)
+{
+ if (!p-mm)
+ return NULL;
+ return
On Tue 26-05-15 13:20:19, Johannes Weiner wrote:
On Tue, May 26, 2015 at 05:11:49PM +0200, Michal Hocko wrote:
On Tue 26-05-15 10:10:11, Johannes Weiner wrote:
On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
@@ -104,7 +105,12 @@ static inline bool mm_match_cgroup(struct
On 05/26, Michal Hocko wrote:
>
> On Tue 26-05-15 18:36:46, Oleg Nesterov wrote:
> >
> > > +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
On Tue 26-05-15 18:36:46, Oleg Nesterov wrote:
> 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
On Tue, May 26, 2015 at 05:11:49PM +0200, Michal Hocko wrote:
> On Tue 26-05-15 10:10:11, Johannes Weiner wrote:
> > On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
> > > @@ -104,7 +105,12 @@ static inline bool mm_match_cgroup(struct mm_struct
> > > *mm,
> > > bool match = false;
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
[CCing Greg who I forgot to add the to list - sorry about that. The
thread starts here: http://marc.info/?l=linux-mm=143264102317318=2]
On Tue 26-05-15 10:10:11, Johannes Weiner wrote:
> On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
> > Please note that this patch introduces a
mm_struct::owner keeps track of the task which is in charge for the
specific mm. This is usually the thread group leader of the task but
there are more exotic cases where this doesn't hold.
The most prominent one is when separate tasks (not in the same thread
group) share the address space (by
On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
> Please note that this patch introduces a USER VISIBLE CHANGE OF BEHAVIOR.
> Without mm->owner _all_ tasks associated with the mm_struct would
> initiate memcg migration while previously only owner of the mm_struct
> could do that. The
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
mm_struct::owner keeps track of the task which is in charge for the
specific mm. This is usually the thread group leader of the task but
there are more exotic cases where this doesn't hold.
The most prominent one is when separate tasks (not in the same thread
group) share the address space (by
[CCing Greg who I forgot to add the to list - sorry about that. The
thread starts here: http://marc.info/?l=linux-mmm=143264102317318w=2]
On Tue 26-05-15 10:10:11, Johannes Weiner wrote:
On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
Please note that this patch introduces a USER
On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
Please note that this patch introduces a USER VISIBLE CHANGE OF BEHAVIOR.
Without mm-owner _all_ tasks associated with the mm_struct would
initiate memcg migration while previously only owner of the mm_struct
could do that. The
On Tue, May 26, 2015 at 05:11:49PM +0200, Michal Hocko wrote:
On Tue 26-05-15 10:10:11, Johannes Weiner wrote:
On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
@@ -104,7 +105,12 @@ static inline bool mm_match_cgroup(struct mm_struct
*mm,
bool match = false;
On Tue 26-05-15 18:36:46, Oleg Nesterov wrote:
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
-*
On 05/26, Michal Hocko wrote:
On Tue 26-05-15 18:36:46, Oleg Nesterov wrote:
+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
34 matches
Mail list logo
