* [patch] mm, memcg: do not allow tasks to be attached with zero limit
@ 2012-03-08 3:14 David Rientjes
2012-03-08 6:15 ` KAMEZAWA Hiroyuki
2012-03-08 20:29 ` Andrew Morton
0 siblings, 2 replies; 8+ messages in thread
From: David Rientjes @ 2012-03-08 3:14 UTC (permalink / raw)
To: Andrew Morton
Cc: Johannes Weiner, Michal Hocko, Balbir Singh, KAMEZAWA Hiroyuki,
cgroups, linux-mm
This patch prevents tasks from being attached to a memcg if there is a
hard limit of zero. Additionally, the hard limit may not be changed to
zero if there are tasks attached.
This is consistent with cpusets which do not allow tasks to be attached
if there are no mems and prevents all mems from being removed if there
are tasks attached.
Signed-off-by: David Rientjes <rientjes@google.com>
---
mm/memcontrol.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3868,9 +3868,14 @@ static int mem_cgroup_write(struct cgroup *cont, struct cftype *cft,
ret = res_counter_memparse_write_strategy(buffer, &val);
if (ret)
break;
- if (type == _MEM)
+ if (type == _MEM) {
+ /* Don't allow zero limit with tasks attached */
+ if (!val && cgroup_task_count(cont)) {
+ ret = -ENOSPC;
+ break;
+ }
ret = mem_cgroup_resize_limit(memcg, val);
- else
+ } else
ret = mem_cgroup_resize_memsw_limit(memcg, val);
break;
case RES_SOFT_LIMIT:
@@ -5306,6 +5311,10 @@ static int mem_cgroup_can_attach(struct cgroup_subsys *ss,
int ret = 0;
struct mem_cgroup *memcg = mem_cgroup_from_cont(cgroup);
+ /* Don't allow tasks attached with a zero limit */
+ if (!res_counter_read_u64(&memcg->res, RES_LIMIT))
+ return -ENOSPC;
+
if (memcg->move_charge_at_immigrate) {
struct mm_struct *mm;
struct mem_cgroup *from = mem_cgroup_from_task(p);
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [patch] mm, memcg: do not allow tasks to be attached with zero limit
2012-03-08 3:14 [patch] mm, memcg: do not allow tasks to be attached with zero limit David Rientjes
@ 2012-03-08 6:15 ` KAMEZAWA Hiroyuki
2012-03-08 20:29 ` Andrew Morton
1 sibling, 0 replies; 8+ messages in thread
From: KAMEZAWA Hiroyuki @ 2012-03-08 6:15 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Johannes Weiner, Michal Hocko, Balbir Singh,
cgroups, linux-mm
On Wed, 7 Mar 2012 19:14:49 -0800 (PST)
David Rientjes <rientjes@google.com> wrote:
> This patch prevents tasks from being attached to a memcg if there is a
> hard limit of zero. Additionally, the hard limit may not be changed to
> zero if there are tasks attached.
>
> This is consistent with cpusets which do not allow tasks to be attached
> if there are no mems and prevents all mems from being removed if there
> are tasks attached.
>
> Signed-off-by: David Rientjes <rientjes@google.com>
I hope Documenation/cgroup/memory.txt should be updated and make this behavior as 'spec'.
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
> mm/memcontrol.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3868,9 +3868,14 @@ static int mem_cgroup_write(struct cgroup *cont, struct cftype *cft,
> ret = res_counter_memparse_write_strategy(buffer, &val);
> if (ret)
> break;
> - if (type == _MEM)
> + if (type == _MEM) {
> + /* Don't allow zero limit with tasks attached */
> + if (!val && cgroup_task_count(cont)) {
> + ret = -ENOSPC;
> + break;
> + }
> ret = mem_cgroup_resize_limit(memcg, val);
> - else
> + } else
> ret = mem_cgroup_resize_memsw_limit(memcg, val);
> break;
> case RES_SOFT_LIMIT:
> @@ -5306,6 +5311,10 @@ static int mem_cgroup_can_attach(struct cgroup_subsys *ss,
> int ret = 0;
> struct mem_cgroup *memcg = mem_cgroup_from_cont(cgroup);
>
> + /* Don't allow tasks attached with a zero limit */
> + if (!res_counter_read_u64(&memcg->res, RES_LIMIT))
> + return -ENOSPC;
> +
> if (memcg->move_charge_at_immigrate) {
> struct mm_struct *mm;
> struct mem_cgroup *from = mem_cgroup_from_task(p);
>
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [patch] mm, memcg: do not allow tasks to be attached with zero limit
2012-03-08 3:14 [patch] mm, memcg: do not allow tasks to be attached with zero limit David Rientjes
2012-03-08 6:15 ` KAMEZAWA Hiroyuki
@ 2012-03-08 20:29 ` Andrew Morton
2012-03-09 1:22 ` KAMEZAWA Hiroyuki
1 sibling, 1 reply; 8+ messages in thread
From: Andrew Morton @ 2012-03-08 20:29 UTC (permalink / raw)
To: David Rientjes
Cc: Johannes Weiner, Michal Hocko, Balbir Singh, KAMEZAWA Hiroyuki,
cgroups, linux-mm
On Wed, 7 Mar 2012 19:14:49 -0800 (PST)
David Rientjes <rientjes@google.com> wrote:
> This patch prevents tasks from being attached to a memcg if there is a
> hard limit of zero.
We're talking about the memcg's limit_in_bytes here, yes?
> Additionally, the hard limit may not be changed to
> zero if there are tasks attached.
hm, well... why? That would be user error, wouldn't it? What is
special about limit_in_bytes=0? The memcg will also be unviable if
limit_in_bytes=1, but we permit that.
IOW, confused.
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch] mm, memcg: do not allow tasks to be attached with zero limit
2012-03-08 20:29 ` Andrew Morton
@ 2012-03-09 1:22 ` KAMEZAWA Hiroyuki
2012-03-09 1:38 ` Andrew Morton
0 siblings, 1 reply; 8+ messages in thread
From: KAMEZAWA Hiroyuki @ 2012-03-09 1:22 UTC (permalink / raw)
To: Andrew Morton
Cc: David Rientjes, Johannes Weiner, Michal Hocko, Balbir Singh,
cgroups, linux-mm
On Thu, 8 Mar 2012 12:29:51 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 7 Mar 2012 19:14:49 -0800 (PST)
> David Rientjes <rientjes@google.com> wrote:
>
> > This patch prevents tasks from being attached to a memcg if there is a
> > hard limit of zero.
>
> We're talking about the memcg's limit_in_bytes here, yes?
>
> > Additionally, the hard limit may not be changed to
> > zero if there are tasks attached.
>
> hm, well... why? That would be user error, wouldn't it? What is
> special about limit_in_bytes=0? The memcg will also be unviable if
> limit_in_bytes=1, but we permit that.
>
> IOW, confused.
>
Ah, yes. limit_in_bytes < some small size can cause the same trouble.
Hmm... should we have configurable min_limit_in_bytes as sysctl or root memcg's
attaribute.. ?
-Kame
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch] mm, memcg: do not allow tasks to be attached with zero limit
2012-03-09 1:22 ` KAMEZAWA Hiroyuki
@ 2012-03-09 1:38 ` Andrew Morton
2012-03-09 1:57 ` KAMEZAWA Hiroyuki
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Morton @ 2012-03-09 1:38 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: David Rientjes, Johannes Weiner, Michal Hocko, Balbir Singh,
cgroups, linux-mm
On Fri, 9 Mar 2012 10:22:55 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Thu, 8 Mar 2012 12:29:51 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Wed, 7 Mar 2012 19:14:49 -0800 (PST)
> > David Rientjes <rientjes@google.com> wrote:
> >
> > > This patch prevents tasks from being attached to a memcg if there is a
> > > hard limit of zero.
> >
> > We're talking about the memcg's limit_in_bytes here, yes?
> >
> > > Additionally, the hard limit may not be changed to
> > > zero if there are tasks attached.
> >
> > hm, well... why? That would be user error, wouldn't it? What is
> > special about limit_in_bytes=0? The memcg will also be unviable if
> > limit_in_bytes=1, but we permit that.
> >
> > IOW, confused.
> >
> Ah, yes. limit_in_bytes < some small size can cause the same trouble.
> Hmm... should we have configurable min_limit_in_bytes as sysctl or root memcg's
> attaribute.. ?
Why do *anything*? If the operator chose an irrational configuration
then things won't work correctly and the operator will then fix the
configuration?
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch] mm, memcg: do not allow tasks to be attached with zero limit
2012-03-09 1:38 ` Andrew Morton
@ 2012-03-09 1:57 ` KAMEZAWA Hiroyuki
2012-03-13 16:51 ` Johannes Weiner
0 siblings, 1 reply; 8+ messages in thread
From: KAMEZAWA Hiroyuki @ 2012-03-09 1:57 UTC (permalink / raw)
To: Andrew Morton
Cc: David Rientjes, Johannes Weiner, Michal Hocko, Balbir Singh,
cgroups, linux-mm
On Thu, 8 Mar 2012 17:38:18 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Fri, 9 Mar 2012 10:22:55 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > On Thu, 8 Mar 2012 12:29:51 -0800
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > On Wed, 7 Mar 2012 19:14:49 -0800 (PST)
> > > David Rientjes <rientjes@google.com> wrote:
> > >
> > > > This patch prevents tasks from being attached to a memcg if there is a
> > > > hard limit of zero.
> > >
> > > We're talking about the memcg's limit_in_bytes here, yes?
> > >
> > > > Additionally, the hard limit may not be changed to
> > > > zero if there are tasks attached.
> > >
> > > hm, well... why? That would be user error, wouldn't it? What is
> > > special about limit_in_bytes=0? The memcg will also be unviable if
> > > limit_in_bytes=1, but we permit that.
> > >
> > > IOW, confused.
> > >
> > Ah, yes. limit_in_bytes < some small size can cause the same trouble.
> > Hmm... should we have configurable min_limit_in_bytes as sysctl or root memcg's
> > attaribute.. ?
>
> Why do *anything*? If the operator chose an irrational configuration
> then things won't work correctly and the operator will then fix the
> configuration?
>
Because the result of 'error operaton' is SIGKILL to a task, which may be
owned by very importang customer of hosting service.
Isn't this severe punishment for error operation ?
Considering again, I have 2 thoughts.
- it should be guarded by MiddleWare, it's not kernel job !
- memcg should be more easy-to-use, friendly to users.
If the result is just an error as EINVAL or EBUSY, I may not be nervous....
Thanks,
-Kame
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch] mm, memcg: do not allow tasks to be attached with zero limit
2012-03-09 1:57 ` KAMEZAWA Hiroyuki
@ 2012-03-13 16:51 ` Johannes Weiner
2012-03-14 9:42 ` Michal Hocko
0 siblings, 1 reply; 8+ messages in thread
From: Johannes Weiner @ 2012-03-13 16:51 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Andrew Morton, David Rientjes, Michal Hocko, Balbir Singh,
cgroups, linux-mm
On Fri, Mar 09, 2012 at 10:57:06AM +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 8 Mar 2012 17:38:18 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Fri, 9 Mar 2012 10:22:55 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >
> > > On Thu, 8 Mar 2012 12:29:51 -0800
> > > Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > > On Wed, 7 Mar 2012 19:14:49 -0800 (PST)
> > > > David Rientjes <rientjes@google.com> wrote:
> > > >
> > > > > This patch prevents tasks from being attached to a memcg if there is a
> > > > > hard limit of zero.
> > > >
> > > > We're talking about the memcg's limit_in_bytes here, yes?
> > > >
> > > > > Additionally, the hard limit may not be changed to
> > > > > zero if there are tasks attached.
> > > >
> > > > hm, well... why? That would be user error, wouldn't it? What is
> > > > special about limit_in_bytes=0? The memcg will also be unviable if
> > > > limit_in_bytes=1, but we permit that.
> > > >
> > > > IOW, confused.
> > > >
> > > Ah, yes. limit_in_bytes < some small size can cause the same trouble.
> > > Hmm... should we have configurable min_limit_in_bytes as sysctl or root memcg's
> > > attaribute.. ?
> >
> > Why do *anything*? If the operator chose an irrational configuration
> > then things won't work correctly and the operator will then fix the
> > configuration?
> >
>
> Because the result of 'error operaton' is SIGKILL to a task, which may be
> owned by very importang customer of hosting service.
>
> Isn't this severe punishment for error operation ?
>
> Considering again, I have 2 thoughts.
>
> - it should be guarded by MiddleWare, it's not kernel job !
> - memcg should be more easy-to-use, friendly to users.
>
> If the result is just an error as EINVAL or EBUSY, I may not be nervous....
You can still disable the OOM killer. If you don't, you can always
get killed, so I'm not convinced by this patch or a sysctl, either.
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch] mm, memcg: do not allow tasks to be attached with zero limit
2012-03-13 16:51 ` Johannes Weiner
@ 2012-03-14 9:42 ` Michal Hocko
0 siblings, 0 replies; 8+ messages in thread
From: Michal Hocko @ 2012-03-14 9:42 UTC (permalink / raw)
To: Johannes Weiner
Cc: KAMEZAWA Hiroyuki, Andrew Morton, David Rientjes, Balbir Singh,
cgroups, linux-mm
On Tue 13-03-12 17:51:18, Johannes Weiner wrote:
> On Fri, Mar 09, 2012 at 10:57:06AM +0900, KAMEZAWA Hiroyuki wrote:
> > On Thu, 8 Mar 2012 17:38:18 -0800
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > On Fri, 9 Mar 2012 10:22:55 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > >
> > > > On Thu, 8 Mar 2012 12:29:51 -0800
> > > > Andrew Morton <akpm@linux-foundation.org> wrote:
> > > >
> > > > > On Wed, 7 Mar 2012 19:14:49 -0800 (PST)
> > > > > David Rientjes <rientjes@google.com> wrote:
> > > > >
> > > > > > This patch prevents tasks from being attached to a memcg if there is a
> > > > > > hard limit of zero.
> > > > >
> > > > > We're talking about the memcg's limit_in_bytes here, yes?
> > > > >
> > > > > > Additionally, the hard limit may not be changed to
> > > > > > zero if there are tasks attached.
> > > > >
> > > > > hm, well... why? That would be user error, wouldn't it? What is
> > > > > special about limit_in_bytes=0? The memcg will also be unviable if
> > > > > limit_in_bytes=1, but we permit that.
> > > > >
> > > > > IOW, confused.
> > > > >
> > > > Ah, yes. limit_in_bytes < some small size can cause the same trouble.
> > > > Hmm... should we have configurable min_limit_in_bytes as sysctl or root memcg's
> > > > attaribute.. ?
> > >
> > > Why do *anything*? If the operator chose an irrational configuration
> > > then things won't work correctly and the operator will then fix the
> > > configuration?
> > >
> >
> > Because the result of 'error operaton' is SIGKILL to a task, which may be
> > owned by very importang customer of hosting service.
> >
> > Isn't this severe punishment for error operation ?
> >
> > Considering again, I have 2 thoughts.
> >
> > - it should be guarded by MiddleWare, it's not kernel job !
> > - memcg should be more easy-to-use, friendly to users.
> >
> > If the result is just an error as EINVAL or EBUSY, I may not be nervous....
>
> You can still disable the OOM killer. If you don't, you can always
> get killed, so I'm not convinced by this patch or a sysctl, either.
Agreed, kernel usually doesn't care about insane settings and it does
what it is told to do (why to safe somebody from shooting its own
foot?).
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-03-14 9:42 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-08 3:14 [patch] mm, memcg: do not allow tasks to be attached with zero limit David Rientjes
2012-03-08 6:15 ` KAMEZAWA Hiroyuki
2012-03-08 20:29 ` Andrew Morton
2012-03-09 1:22 ` KAMEZAWA Hiroyuki
2012-03-09 1:38 ` Andrew Morton
2012-03-09 1:57 ` KAMEZAWA Hiroyuki
2012-03-13 16:51 ` Johannes Weiner
2012-03-14 9:42 ` Michal Hocko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).