From: Glauber Costa <hidden> Date: 2011-12-12 07:48:38
Hi,
This series fixes all the few comments raised in the last round,
and seem to have acquired consensus from the memcg side.
Dave, do you think it is acceptable now from the networking PoV?
In case positive, would you prefer merging this trough your tree,
or acking this so a cgroup maintainer can do it?
Thanks
Glauber Costa (9):
Basic kernel memory functionality for the Memory Controller
foundations of per-cgroup memory pressure controlling.
socket: initial cgroup code.
tcp memory pressure controls
per-netns ipv4 sysctl_tcp_mem
tcp buffer limitation: per-cgroup limit
Display current tcp memory allocation in kmem cgroup
Display current tcp failcnt in kmem cgroup
Display maximum tcp memory allocation in kmem cgroup
Documentation/cgroups/memory.txt | 46 ++++++-
include/linux/memcontrol.h | 23 ++++
include/net/netns/ipv4.h | 1 +
include/net/sock.h | 244 +++++++++++++++++++++++++++++++++-
include/net/tcp.h | 4 +-
include/net/tcp_memcontrol.h | 19 +++
init/Kconfig | 11 ++
mm/memcontrol.c | 191 +++++++++++++++++++++++++-
net/core/sock.c | 112 ++++++++++++----
net/ipv4/Makefile | 1 +
net/ipv4/af_inet.c | 2 +
net/ipv4/proc.c | 6 +-
net/ipv4/sysctl_net_ipv4.c | 65 ++++++++-
net/ipv4/tcp.c | 11 +--
net/ipv4/tcp_input.c | 12 +-
net/ipv4/tcp_ipv4.c | 14 ++-
net/ipv4/tcp_memcontrol.c | 272 ++++++++++++++++++++++++++++++++++++++
net/ipv4/tcp_output.c | 2 +-
net/ipv4/tcp_timer.c | 2 +-
net/ipv6/af_inet6.c | 2 +
net/ipv6/tcp_ipv6.c | 8 +-
21 files changed, 973 insertions(+), 75 deletions(-)
create mode 100644 include/net/tcp_memcontrol.h
create mode 100644 net/ipv4/tcp_memcontrol.c
--
1.7.6.4
--
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>
From: Glauber Costa <hidden> Date: 2011-12-12 07:48:46
The goal of this work is to move the memory pressure tcp
controls to a cgroup, instead of just relying on global
conditions.
To avoid excessive overhead in the network fast paths,
the code that accounts allocated memory to a cgroup is
hidden inside a static_branch(). This branch is patched out
until the first non-root cgroup is created. So when nobody
is using cgroups, even if it is mounted, no significant performance
penalty should be seen.
This patch handles the generic part of the code, and has nothing
tcp-specific.
Signed-off-by: Glauber Costa <redacted>
Reviewed-by: KAMEZAWA Hiroyuki <redacted>
CC: Kirill A. Shutemov <redacted>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <redacted>
CC: Eric Dumazet <redacted>
---
Documentation/cgroups/memory.txt | 4 +-
include/linux/memcontrol.h | 22 ++++++
include/net/sock.h | 156 ++++++++++++++++++++++++++++++++++++--
mm/memcontrol.c | 46 +++++++++++-
net/core/sock.c | 24 ++++--
5 files changed, 235 insertions(+), 17 deletions(-)
@@ -289,7 +289,9 @@ to trigger slab reclaim when those limits are reached. 2.7.1 Current Kernel Memory resources accounted-None+* sockets memory pressure: some sockets protocols have memory pressure+thresholds. The Memory Controller allows them to be controlled individually+per cgroup, instead of globally. 3. User Interface
@@ -834,6 +838,37 @@ struct proto {#ifdef SOCK_REFCNT_DEBUGatomic_tsocks;#endif+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM+/*+*cgroupspecificinit/deinitfunctions.Calledonceforall+*protocolsthatimplementit,fromcgroupspopulatefunction.+*Thisfunctionhastosetupanyfilestheprotocolwantto+*appearinthekmemcgroupfilesystem.+*/+int(*init_cgroup)(structcgroup*cgrp,+structcgroup_subsys*ss);+void(*destroy_cgroup)(structcgroup*cgrp,+structcgroup_subsys*ss);+structcg_proto*(*proto_cgroup)(structmem_cgroup*memcg);+#endif+};++structcg_proto{+void(*enter_memory_pressure)(structsock*sk);+structres_counter*memory_allocated;/* Current allocated memory. */+structpercpu_counter*sockets_allocated;/* Current number of sockets. */+int*memory_pressure;+long*sysctl_mem;+/*+*memcgfieldisusedtofindwhichmemcgwebelongdirectly+*Eachmemcgstructcanholdmorethanonecg_proto,socontainer_of+*won'treallycut.+*+*Theelegantsolutionwouldbehavinganinversefunctionto+*proto_cgroupinstructproto,butthatmeanspollutingthestructure+*foreverybody,insteadofjustformemcgusers.+*/+structmem_cgroup*memcg;};externintproto_register(structproto*prot,intalloc_slab);
@@ -852,7 +887,7 @@ static inline void sk_refcnt_debug_dec(struct sock *sk)sk->sk_prot->name,sk,atomic_read(&sk->sk_prot->socks));}-staticinlinevoidsk_refcnt_debug_release(conststructsock*sk)+inlinevoidsk_refcnt_debug_release(conststructsock*sk){if(atomic_read(&sk->sk_refcnt)!=1)printk(KERN_DEBUG"Destruction of the %s socket %p delayed, refcnt=%d\n",
@@ -379,7 +379,48 @@ enum mem_type {staticvoidmem_cgroup_get(structmem_cgroup*memcg);staticvoidmem_cgroup_put(structmem_cgroup*memcg);-staticstructmem_cgroup*parent_mem_cgroup(structmem_cgroup*memcg);++/* Writing them here to avoid exposing memcg's inner layout */+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM+#ifdef CONFIG_INET+#include<net/sock.h>++staticboolmem_cgroup_is_root(structmem_cgroup*memcg);+voidsock_update_memcg(structsock*sk)+{+/* A socket spends its whole life in the same cgroup */+if(sk->sk_cgrp){+WARN_ON(1);+return;+}+if(static_branch(&memcg_socket_limit_enabled)){+structmem_cgroup*memcg;++BUG_ON(!sk->sk_prot->proto_cgroup);++rcu_read_lock();+memcg=mem_cgroup_from_task(current);+if(!mem_cgroup_is_root(memcg)){+mem_cgroup_get(memcg);+sk->sk_cgrp=sk->sk_prot->proto_cgroup(memcg);+}+rcu_read_unlock();+}+}+EXPORT_SYMBOL(sock_update_memcg);++voidsock_release_memcg(structsock*sk)+{+if(static_branch(&memcg_socket_limit_enabled)&&sk->sk_cgrp){+structmem_cgroup*memcg;+WARN_ON(!sk->sk_cgrp->memcg);+memcg=sk->sk_cgrp->memcg;+mem_cgroup_put(memcg);+}+}+#endif /* CONFIG_INET */+#endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */+staticvoiddrain_all_stock_async(structmem_cgroup*memcg);staticstructmem_cgroup_per_zone*
@@ -1677,23 +1681,27 @@ int __sk_mem_schedule(struct sock *sk, int size, int kind)structproto*prot=sk->sk_prot;intamt=sk_mem_pages(size);longallocated;+intparent_status=UNDER_LIMIT;sk->sk_forward_alloc+=amt*SK_MEM_QUANTUM;-allocated=sk_memory_allocated_add(sk,amt);+allocated=sk_memory_allocated_add(sk,amt,&parent_status);/* Under limit. */-if(allocated<=sk_prot_mem_limits(sk,0)){+if(parent_status==UNDER_LIMIT&&+allocated<=sk_prot_mem_limits(sk,0)){sk_leave_memory_pressure(sk);return1;}-/* Under pressure. */-if(allocated>sk_prot_mem_limits(sk,1))+/* Under pressure. (we or our parents) */+if((parent_status>SOFT_LIMIT)||+allocated>sk_prot_mem_limits(sk,1))sk_enter_memory_pressure(sk);-/* Over hard limit. */-if(allocated>sk_prot_mem_limits(sk,2))+/* Over hard limit (we or our parents) */+if((parent_status==OVER_LIMIT)||+(allocated>sk_prot_mem_limits(sk,2)))gotosuppress_allocation;/* guarantee minimum buffer size under pressure */
--
1.7.6.4
--
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>
From: Jason Baron <hidden> Date: 2011-12-22 21:10:51
On Mon, Dec 12, 2011 at 11:47:03AM +0400, Glauber Costa wrote:
+
+static bool mem_cgroup_is_root(struct mem_cgroup *memcg);
+void sock_update_memcg(struct sock *sk)
+{
+ /* A socket spends its whole life in the same cgroup */
+ if (sk->sk_cgrp) {
+ WARN_ON(1);
+ return;
+ }
+ if (static_branch(&memcg_socket_limit_enabled)) {
+ struct mem_cgroup *memcg;
+
+ BUG_ON(!sk->sk_prot->proto_cgroup);
+
+ rcu_read_lock();
+ memcg = mem_cgroup_from_task(current);
+ if (!mem_cgroup_is_root(memcg)) {
+ mem_cgroup_get(memcg);
+ sk->sk_cgrp = sk->sk_prot->proto_cgroup(memcg);
+ }
+ rcu_read_unlock();
+ }
+}
+EXPORT_SYMBOL(sock_update_memcg);
+
+void sock_release_memcg(struct sock *sk)
+{
+ if (static_branch(&memcg_socket_limit_enabled) && sk->sk_cgrp) {
+ struct mem_cgroup *memcg;
+ WARN_ON(!sk->sk_cgrp->memcg);
+ memcg = sk->sk_cgrp->memcg;
+ mem_cgroup_put(memcg);
+ }
+}
Hi Glauber,
I think for 'sock_release_memcg()', you want:
static inline sock_release_memcg(sk)
{
if (static_branch())
__sock_release_memcg();
}
And then re-define the current sock_release_memcg -> __sock_release_memcg().
In that way the straight line path is a single no-op. As currently
written, there is function call and then an immediate return.
Thanks,
-Jason
--
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>
From: Glauber Costa <hidden> Date: 2011-12-23 08:58:40
On 12/23/2011 01:10 AM, Jason Baron wrote:
On Mon, Dec 12, 2011 at 11:47:03AM +0400, Glauber Costa wrote:
quoted
+
+static bool mem_cgroup_is_root(struct mem_cgroup *memcg);
+void sock_update_memcg(struct sock *sk)
+{
+ /* A socket spends its whole life in the same cgroup */
+ if (sk->sk_cgrp) {
+ WARN_ON(1);
+ return;
+ }
+ if (static_branch(&memcg_socket_limit_enabled)) {
+ struct mem_cgroup *memcg;
+
+ BUG_ON(!sk->sk_prot->proto_cgroup);
+
+ rcu_read_lock();
+ memcg = mem_cgroup_from_task(current);
+ if (!mem_cgroup_is_root(memcg)) {
+ mem_cgroup_get(memcg);
+ sk->sk_cgrp = sk->sk_prot->proto_cgroup(memcg);
+ }
+ rcu_read_unlock();
+ }
+}
+EXPORT_SYMBOL(sock_update_memcg);
+
+void sock_release_memcg(struct sock *sk)
+{
+ if (static_branch(&memcg_socket_limit_enabled)&& sk->sk_cgrp) {
+ struct mem_cgroup *memcg;
+ WARN_ON(!sk->sk_cgrp->memcg);
+ memcg = sk->sk_cgrp->memcg;
+ mem_cgroup_put(memcg);
+ }
+}
Hi Glauber,
I think for 'sock_release_memcg()', you want:
static inline sock_release_memcg(sk)
{
if (static_branch())
__sock_release_memcg();
}
And then re-define the current sock_release_memcg -> __sock_release_memcg().
In that way the straight line path is a single no-op. As currently
written, there is function call and then an immediate return.
Hello Jason,
Thanks for the tip. I may be wrong here, but I don't think that the
release performance matters to that level. But your suggestion seems
good nevertheless. Since this is already sitting on a tree, would you
like to send a patch for that?
--
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>
From: Glauber Costa <hidden> Date: 2011-12-12 07:48:51
This patch replaces all uses of struct sock fields' memory_pressure,
memory_allocated, sockets_allocated, and sysctl_mem to acessor
macros. Those macros can either receive a socket argument, or a mem_cgroup
argument, depending on the context they live in.
Since we're only doing a macro wrapping here, no performance impact at all is
expected in the case where we don't have cgroups disabled.
Signed-off-by: Glauber Costa <redacted>
Reviewed-by: Hiroyouki Kamezawa <redacted>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <redacted>
CC: Eric Dumazet <redacted>
---
include/net/sock.h | 96 ++++++++++++++++++++++++++++++++++++++++++++++++-
include/net/tcp.h | 3 +-
net/core/sock.c | 57 +++++++++++++++++------------
net/ipv4/proc.c | 6 ++--
net/ipv4/tcp_input.c | 12 +++---
net/ipv4/tcp_ipv4.c | 4 +-
net/ipv4/tcp_output.c | 2 +-
net/ipv4/tcp_timer.c | 2 +-
net/ipv6/tcp_ipv6.c | 2 +-
9 files changed, 145 insertions(+), 39 deletions(-)
@@ -1679,28 +1679,28 @@ int __sk_mem_schedule(struct sock *sk, int size, int kind)longallocated;sk->sk_forward_alloc+=amt*SK_MEM_QUANTUM;-allocated=atomic_long_add_return(amt,prot->memory_allocated);++allocated=sk_memory_allocated_add(sk,amt);/* Under limit. */-if(allocated<=prot->sysctl_mem[0]){-if(prot->memory_pressure&&*prot->memory_pressure)-*prot->memory_pressure=0;+if(allocated<=sk_prot_mem_limits(sk,0)){+sk_leave_memory_pressure(sk);return1;}/* Under pressure. */-if(allocated>prot->sysctl_mem[1])-if(prot->enter_memory_pressure)-prot->enter_memory_pressure(sk);+if(allocated>sk_prot_mem_limits(sk,1))+sk_enter_memory_pressure(sk);/* Over hard limit. */-if(allocated>prot->sysctl_mem[2])+if(allocated>sk_prot_mem_limits(sk,2))gotosuppress_allocation;/* guarantee minimum buffer size under pressure */if(kind==SK_MEM_RECV){if(atomic_read(&sk->sk_rmem_alloc)<prot->sysctl_rmem[0])return1;+}else{/* SK_MEM_SEND */if(sk->sk_type==SOCK_STREAM){if(sk->sk_wmem_queued<prot->sysctl_wmem[0])
@@ -1710,13 +1710,13 @@ int __sk_mem_schedule(struct sock *sk, int size, int kind)return1;}-if(prot->memory_pressure){+if(sk_has_memory_pressure(sk)){intalloc;-if(!*prot->memory_pressure)+if(!sk_under_memory_pressure(sk))return1;-alloc=percpu_counter_read_positive(prot->sockets_allocated);-if(prot->sysctl_mem[2]>alloc*+alloc=sk_sockets_allocated_read_positive(sk);+if(sk_prot_mem_limits(sk,2)>alloc*sk_mem_pages(sk->sk_wmem_queued+atomic_read(&sk->sk_rmem_alloc)+sk->sk_forward_alloc))
@@ -4864,7 +4864,7 @@ static int tcp_prune_queue(struct sock *sk)if(atomic_read(&sk->sk_rmem_alloc)>=sk->sk_rcvbuf)tcp_clamp_window(sk);-elseif(tcp_memory_pressure)+elseif(sk_under_memory_pressure(sk))tp->rcv_ssthresh=min(tp->rcv_ssthresh,4U*tp->advmss);tcp_collapse_ofo_queue(sk);
@@ -4930,11 +4930,11 @@ static int tcp_should_expand_sndbuf(const struct sock *sk)return0;/* If we are under global TCP memory pressure, do not expand. */-if(tcp_memory_pressure)+if(sk_under_memory_pressure(sk))return0;/* If we are under soft global TCP memory pressure, do not expand. */-if(atomic_long_read(&tcp_memory_allocated)>=sysctl_tcp_mem[0])+if(sk_memory_allocated(sk)>=sk_prot_mem_limits(sk,0))return0;/* If we filled the congestion window, do not expand. */
@@ -1995,7 +1995,7 @@ static int tcp_v6_init_sock(struct sock *sk)sk->sk_rcvbuf=sysctl_tcp_rmem[1];local_bh_disable();-percpu_counter_inc(&tcp_sockets_allocated);+sk_sockets_allocated_inc(sk);local_bh_enable();return0;
--
1.7.6.4
--
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>
From: Glauber Costa <hidden> Date: 2011-12-12 07:48:55
This patch uses the "tcp.limit_in_bytes" field of the kmem_cgroup to
effectively control the amount of kernel memory pinned by a cgroup.
This value is ignored in the root cgroup, and in all others,
caps the value specified by the admin in the net namespaces'
view of tcp_sysctl_mem.
If namespaces are being used, the admin is allowed to set a
value bigger than cgroup's maximum, the same way it is allowed
to set pretty much unlimited values in a real box.
Signed-off-by: Glauber Costa <redacted>
Reviewed-by: Hiroyouki Kamezawa <redacted>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <redacted>
---
Documentation/cgroups/memory.txt | 1 +
include/net/tcp_memcontrol.h | 2 +
net/ipv4/sysctl_net_ipv4.c | 14 ++++
net/ipv4/tcp_memcontrol.c | 137 +++++++++++++++++++++++++++++++++++++-
4 files changed, 152 insertions(+), 2 deletions(-)
@@ -78,6 +78,7 @@ Brief summary of control files. memory.independent_kmem_limit # select whether or not kernel memory limits are independent of user limits+ memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory 1. History
--
1.7.6.4
--
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>
From: Glauber Costa <hidden> Date: 2011-12-12 07:49:03
This patch introduces kmem.tcp.failcnt file, living in the
kmem_cgroup filesystem. Following the pattern in the other
memcg resources, this files keeps a counter of how many times
allocation failed due to limits being hit in this cgroup.
The root cgroup will always show a failcnt of 0.
Signed-off-by: Glauber Costa <redacted>
Reviewed-by: Hiroyouki Kamezawa <redacted>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <redacted>
---
net/ipv4/tcp_memcontrol.c | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
--
1.7.6.4
--
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>
From: Glauber Costa <hidden> Date: 2011-12-12 07:49:23
This patch introduces kmem.tcp.max_usage_in_bytes file, living in the
kmem_cgroup filesystem. The root cgroup will display a value equal
to RESOURCE_MAX. This is to avoid introducing any locking schemes in
the network paths when cgroups are not being actively used.
All others, will see the maximum memory ever used by this cgroup.
Signed-off-by: Glauber Costa <redacted>
Reviewed-by: Hiroyouki Kamezawa <redacted>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <redacted>
---
net/ipv4/tcp_memcontrol.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
@@ -226,6 +233,9 @@ static int tcp_cgroup_reset(struct cgroup *cont, unsigned int event)tcp=tcp_from_cgproto(cg_proto);switch(event){+caseRES_MAX_USAGE:+res_counter_reset_max(&tcp->tcp_memory_allocated);+break;caseRES_FAILCNT:res_counter_reset_failcnt(&tcp->tcp_memory_allocated);break;
--
1.7.6.4
--
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>
From: Glauber Costa <hidden> Date: 2011-12-12 07:49:47
This patch lays down the foundation for the kernel memory component
of the Memory Controller.
As of today, I am only laying down the following files:
* memory.independent_kmem_limit
* memory.kmem.limit_in_bytes (currently ignored)
* memory.kmem.usage_in_bytes (always zero)
Signed-off-by: Glauber Costa <redacted>
CC: Kirill A. Shutemov <redacted>
CC: Paul Menage <redacted>
CC: Greg Thelen <redacted>
CC: Johannes Weiner <redacted>
CC: Michal Hocko <redacted>
---
Documentation/cgroups/memory.txt | 40 ++++++++++++++-
init/Kconfig | 11 ++++
mm/memcontrol.c | 105 ++++++++++++++++++++++++++++++++++++--
3 files changed, 149 insertions(+), 7 deletions(-)
@@ -44,8 +44,9 @@ Features: - oom-killer disable knob and oom-notifier - Root cgroup has no limit controls.- Kernel memory and Hugepages are not under control yet. We just manage- pages on LRU. To add more controls, we have to take care of performance.+ Hugepages is not under control yet. We just manage pages on LRU. To add more+ controls, we have to take care of performance. Kernel memory support is work+ in progress, and the current version provides basically functionality. Brief summary of control files.
@@ -56,8 +57,11 @@ Brief summary of control files. (See 5.5 for details) memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap (See 5.5 for details)+ memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.+ (See 2.7 for details) memory.limit_in_bytes # set/show limit of memory usage memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage+ memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory memory.failcnt # show the number of memory usage hits limits memory.memsw.failcnt # show the number of memory+Swap hits limits memory.max_usage_in_bytes # show max memory usage recorded
@@ -72,6 +76,9 @@ Brief summary of control files. memory.oom_control # set/show oom controls. memory.numa_stat # show the number of memory usage per numa node+ memory.independent_kmem_limit # select whether or not kernel memory limits are+ independent of user limits+ 1. History The memory controller has a long history. A request for comments for the memory
@@ -255,6 +262,35 @@ When oom event notifier is registered, event will be delivered. per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by zone->lru_lock, it has no lock of its own.+2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)++With the Kernel memory extension, the Memory Controller is able to limit+the amount of kernel memory used by the system. Kernel memory is fundamentally+different than user memory, since it can't be swapped out, which makes it+possible to DoS the system by consuming too much of this precious resource.++Some kernel memory resources may be accounted and limited separately from the+main "kmem" resource. For instance, a slab cache that is considered important+enough to be limited separately may have its own knobs.++Kernel memory limits are not imposed for the root cgroup. Usage for the root+cgroup may or may not be accounted.++Memory limits as specified by the standard Memory Controller may or may not+take kernel memory into consideration. This is achieved through the file+memory.independent_kmem_limit. A Value different than 0 will allow for kernel+memory to be controlled separately.++When kernel memory limits are not independent, the limit values set in+memory.kmem files are ignored.++Currently no soft limit is implemented for kernel memory. It is future work+to trigger slab reclaim when those limits are reached.++2.7.1 Current Kernel Memory resources accounted++None+ 3. User Interface 0. Configuration
@@ -4978,6 +5069,10 @@ static int mem_cgroup_populate(struct cgroup_subsys *ss,if(!ret)ret=register_memsw_files(cont,ss);++if(!ret)+ret=register_kmem_files(cont,ss);+returnret;}
--
1.7.6.4
--
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>
From: Michal Hocko <hidden> Date: 2011-12-14 17:04:53
[Now with the current patch version, I hope]
On Mon 12-12-11 11:47:01, Glauber Costa wrote:
This patch lays down the foundation for the kernel memory component
of the Memory Controller.
As of today, I am only laying down the following files:
* memory.independent_kmem_limit
Maybe has been already discussed but the name is rather awkward and it
would deserve more clarification. It is independent in the way that it
doesn't add up to the standard (user) allocations or it enables/disables
accounting?
* memory.kmem.limit_in_bytes (currently ignored)
What happens if we reach the limit? Are all kernel allocations
considered or only selected caches? How do I find out which are those?
AFAIU you have implemented it for network buffers at this stage but I
guess that dentries will follow...
quoted hunk
* memory.kmem.usage_in_bytes (always zero)
Signed-off-by: Glauber Costa <redacted>
CC: Kirill A. Shutemov <redacted>
CC: Paul Menage <redacted>
CC: Greg Thelen <redacted>
CC: Johannes Weiner <redacted>
CC: Michal Hocko <redacted>
---
Documentation/cgroups/memory.txt | 40 ++++++++++++++-
init/Kconfig | 11 ++++
mm/memcontrol.c | 105 ++++++++++++++++++++++++++++++++++++--
3 files changed, 149 insertions(+), 7 deletions(-)
@@ -44,8 +44,9 @@ Features: - oom-killer disable knob and oom-notifier - Root cgroup has no limit controls.- Kernel memory and Hugepages are not under control yet. We just manage- pages on LRU. To add more controls, we have to take care of performance.+ Hugepages is not under control yet. We just manage pages on LRU. To add more
Hugepages are not
Anyway this sounds outdated as we track both THP and hugetlb, right?
+ controls, we have to take care of performance. Kernel memory support is work
+ in progress, and the current version provides basically functionality.
s/basically/basic/
quoted hunk
Brief summary of control files.
@@ -56,8 +57,11 @@ Brief summary of control files. (See 5.5 for details) memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap (See 5.5 for details)+ memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.+ (See 2.7 for details) memory.limit_in_bytes # set/show limit of memory usage memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage+ memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory memory.failcnt # show the number of memory usage hits limits memory.memsw.failcnt # show the number of memory+Swap hits limits memory.max_usage_in_bytes # show max memory usage recorded
@@ -72,6 +76,9 @@ Brief summary of control files. memory.oom_control # set/show oom controls. memory.numa_stat # show the number of memory usage per numa node+ memory.independent_kmem_limit # select whether or not kernel memory limits are+ independent of user limits+
It is not clear what happens in enabled/disabled cases. Let's say they
are not independent. Does it form a single limit with user charges or it
toggles kmem charging on/off.
quoted hunk
1. History
The memory controller has a long history. A request for comments for the memory
@@ -255,6 +262,35 @@ When oom event notifier is registered, event will be delivered. per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by zone->lru_lock, it has no lock of its own.+2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)++With the Kernel memory extension, the Memory Controller is able to limit+the amount of kernel memory used by the system. Kernel memory is fundamentally+different than user memory, since it can't be swapped out, which makes it+possible to DoS the system by consuming too much of this precious resource.++Some kernel memory resources may be accounted and limited separately from the+main "kmem" resource. For instance, a slab cache that is considered important+enough to be limited separately may have its own knobs.
How do you tell which are those that are accounted to the "main kmem"?
+
+Kernel memory limits are not imposed for the root cgroup. Usage for the root
+cgroup may or may not be accounted.
+
+Memory limits as specified by the standard Memory Controller may or may not
+take kernel memory into consideration. This is achieved through the file
+memory.independent_kmem_limit. A Value different than 0 will allow for kernel
+memory to be controlled separately.
Separately from user space allocations, right?
What happens if we reach the limit in both cases?
quoted hunk
@@ -344,9 +353,14 @@ enum charge_type { }; /* for encoding cft->private value on file */-#define _MEM (0)-#define _MEMSWAP (1)-#define _OOM_TYPE (2)++enum mem_type {+ _MEM = 0,+ _MEMSWAP,+ _OOM_TYPE,+ _KMEM,+};+
@@ -3848,10 +3862,17 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *memcg, bool swap) u64 val; if (!mem_cgroup_is_root(memcg)) {+ val = 0;+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM+ if (!memcg->kmem_independent_accounting)+ val = res_counter_read_u64(&memcg->kmem, RES_USAGE);+#endif if (!swap)- return res_counter_read_u64(&memcg->res, RES_USAGE);+ val += res_counter_read_u64(&memcg->res, RES_USAGE); else- return res_counter_read_u64(&memcg->memsw, RES_USAGE);+ val += res_counter_read_u64(&memcg->memsw, RES_USAGE);++ return val; }
So you report kmem+user but we do not consider kmem during charge so one
can easily end up with usage_in_bytes over limit but no reclaim is going
on. Not good, I would say.
OK, so to sum it up. The biggest problem I see is the (non)independent
accounting. We simply cannot mix user+kernel limits otherwise we would
see issues (like kernel resource hog would force memcg-oom and innocent
members would die because their rss is much bigger).
It is also not clear to me what should happen when we hit the kmem
limit. I guess it will be kmem cache dependent.
--
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>
From: Glauber Costa <hidden> Date: 2011-12-15 12:30:03
On 12/14/2011 09:04 PM, Michal Hocko wrote:
[Now with the current patch version, I hope]
On Mon 12-12-11 11:47:01, Glauber Costa wrote:
quoted
This patch lays down the foundation for the kernel memory component
of the Memory Controller.
As of today, I am only laying down the following files:
* memory.independent_kmem_limit
Maybe has been already discussed but the name is rather awkward and it
would deserve more clarification. It is independent in the way that it
doesn't add up to the standard (user) allocations or it enables/disables
accounting?
If turned on, it doesn't add up to the user allocations.
As for the name, this is marked experimental, so I don't think anyone
will be relying on it for a while. We can change it, if you have a
better suggestion.
quoted
* memory.kmem.limit_in_bytes (currently ignored)
What happens if we reach the limit? Are all kernel allocations
considered or only selected caches? How do I find out which are those?
AFAIU you have implemented it for network buffers at this stage but I
guess that dentries will follow...
Further allocations should fail.
About other caches, tcp is a bit different because we are concerned with
conditions that applies after the allocation already took place. It is
not clear to me if we will treat the other caches as a single entity, or
separate them.
@@ -44,8 +44,9 @@ Features: - oom-killer disable knob and oom-notifier - Root cgroup has no limit controls.- Kernel memory and Hugepages are not under control yet. We just manage- pages on LRU. To add more controls, we have to take care of performance.+ Hugepages is not under control yet. We just manage pages on LRU. To add more
Hugepages are not
Anyway this sounds outdated as we track both THP and hugetlb, right?
quoted
+ controls, we have to take care of performance. Kernel memory support is work
+ in progress, and the current version provides basically functionality.
s/basically/basic/
quoted
Brief summary of control files.
@@ -56,8 +57,11 @@ Brief summary of control files. (See 5.5 for details) memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap (See 5.5 for details)+ memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.+ (See 2.7 for details) memory.limit_in_bytes # set/show limit of memory usage memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage+ memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory memory.failcnt # show the number of memory usage hits limits memory.memsw.failcnt # show the number of memory+Swap hits limits memory.max_usage_in_bytes # show max memory usage recorded
@@ -72,6 +76,9 @@ Brief summary of control files. memory.oom_control # set/show oom controls. memory.numa_stat # show the number of memory usage per numa node+ memory.independent_kmem_limit # select whether or not kernel memory limits are+ independent of user limits+
It is not clear what happens in enabled/disabled cases. Let's say they
are not independent. Does it form a single limit with user charges or it
toggles kmem charging on/off.
quoted
1. History
The memory controller has a long history. A request for comments for the memory
@@ -255,6 +262,35 @@ When oom event notifier is registered, event will be delivered. per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by zone->lru_lock, it has no lock of its own.+2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)++With the Kernel memory extension, the Memory Controller is able to limit+the amount of kernel memory used by the system. Kernel memory is fundamentally+different than user memory, since it can't be swapped out, which makes it+possible to DoS the system by consuming too much of this precious resource.++Some kernel memory resources may be accounted and limited separately from the+main "kmem" resource. For instance, a slab cache that is considered important+enough to be limited separately may have its own knobs.
How do you tell which are those that are accounted to the "main kmem"?
Besides being in this list, they should have they own files, like tcp.
quoted
+
+Kernel memory limits are not imposed for the root cgroup. Usage for the root
+cgroup may or may not be accounted.
+
+Memory limits as specified by the standard Memory Controller may or may not
+take kernel memory into consideration. This is achieved through the file
+memory.independent_kmem_limit. A Value different than 0 will allow for kernel
+memory to be controlled separately.
Separately from user space allocations, right?
Yes.
What happens if we reach the limit in both cases?
For kernel memory, further allocations should fail.
quoted
@@ -344,9 +353,14 @@ enum charge_type { }; /* for encoding cft->private value on file */-#define _MEM (0)-#define _MEMSWAP (1)-#define _OOM_TYPE (2)++enum mem_type {+ _MEM = 0,+ _MEMSWAP,+ _OOM_TYPE,+ _KMEM,+};+
@@ -3848,10 +3862,17 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *memcg, bool swap) u64 val; if (!mem_cgroup_is_root(memcg)) {+ val = 0;+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM+ if (!memcg->kmem_independent_accounting)+ val = res_counter_read_u64(&memcg->kmem, RES_USAGE);+#endif if (!swap)- return res_counter_read_u64(&memcg->res, RES_USAGE);+ val += res_counter_read_u64(&memcg->res, RES_USAGE); else- return res_counter_read_u64(&memcg->memsw, RES_USAGE);+ val += res_counter_read_u64(&memcg->memsw, RES_USAGE);++ return val; }
So you report kmem+user but we do not consider kmem during charge so one
can easily end up with usage_in_bytes over limit but no reclaim is going
on. Not good, I would say.
OK, so to sum it up. The biggest problem I see is the (non)independent
accounting. We simply cannot mix user+kernel limits otherwise we would
see issues (like kernel resource hog would force memcg-oom and innocent
members would die because their rss is much bigger).
It is also not clear to me what should happen when we hit the kmem
limit. I guess it will be kmem cache dependent.
So right now, tcp is completely independent, since it is not accounted
to kmem. In summary, we still never do non-independent accounting. When
we start doing it for the other caches, We will have to add a test at
charge time as well.
We still need to keep it separate though, in case the independent flag
is turned on/off
--
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>
From: Michal Hocko <hidden> Date: 2011-12-16 12:33:05
On Thu 15-12-11 16:29:18, Glauber Costa wrote:
On 12/14/2011 09:04 PM, Michal Hocko wrote:
quoted
[Now with the current patch version, I hope]
On Mon 12-12-11 11:47:01, Glauber Costa wrote:
[...]
quoted
quoted
@@ -3848,10 +3862,17 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *memcg, bool swap) u64 val; if (!mem_cgroup_is_root(memcg)) {+ val = 0;+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM+ if (!memcg->kmem_independent_accounting)+ val = res_counter_read_u64(&memcg->kmem, RES_USAGE);+#endif if (!swap)- return res_counter_read_u64(&memcg->res, RES_USAGE);+ val += res_counter_read_u64(&memcg->res, RES_USAGE); else- return res_counter_read_u64(&memcg->memsw, RES_USAGE);+ val += res_counter_read_u64(&memcg->memsw, RES_USAGE);++ return val; }
So you report kmem+user but we do not consider kmem during charge so one
can easily end up with usage_in_bytes over limit but no reclaim is going
on. Not good, I would say.
I find this a problem and one of the reason I do not like !independent
accounting.
quoted
OK, so to sum it up. The biggest problem I see is the (non)independent
accounting. We simply cannot mix user+kernel limits otherwise we would
see issues (like kernel resource hog would force memcg-oom and innocent
members would die because their rss is much bigger).
It is also not clear to me what should happen when we hit the kmem
limit. I guess it will be kmem cache dependent.
So right now, tcp is completely independent, since it is not
accounted to kmem.
So why do we need kmem accounting when tcp (the only user at the moment)
doesn't use it?
In summary, we still never do non-independent accounting. When we
start doing it for the other caches, We will have to add a test at
charge time as well.
So we shouldn't do it as a part of this patchset because the further
usage is not clear and I think there will be some real issues with
user+kmem accounting (e.g. a proper memcg-oom implementation).
Can you just drop this patch?
We still need to keep it separate though, in case the independent
flag is turned on/off
I don't mind to have kmem.tcp.* knobs.
--
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>
From: Glauber Costa <hidden> Date: 2011-12-16 13:03:44
On 12/16/2011 04:32 PM, Michal Hocko wrote:
On Thu 15-12-11 16:29:18, Glauber Costa wrote:
quoted
On 12/14/2011 09:04 PM, Michal Hocko wrote:
quoted
[Now with the current patch version, I hope]
On Mon 12-12-11 11:47:01, Glauber Costa wrote:
[...]
quoted
quoted
quoted
@@ -3848,10 +3862,17 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *memcg, bool swap) u64 val; if (!mem_cgroup_is_root(memcg)) {+ val = 0;+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM+ if (!memcg->kmem_independent_accounting)+ val = res_counter_read_u64(&memcg->kmem, RES_USAGE);+#endif if (!swap)- return res_counter_read_u64(&memcg->res, RES_USAGE);+ val += res_counter_read_u64(&memcg->res, RES_USAGE); else- return res_counter_read_u64(&memcg->memsw, RES_USAGE);+ val += res_counter_read_u64(&memcg->memsw, RES_USAGE);++ return val; }
So you report kmem+user but we do not consider kmem during charge so one
can easily end up with usage_in_bytes over limit but no reclaim is going
on. Not good, I would say.
I find this a problem and one of the reason I do not like !independent
accounting.
quoted
quoted
OK, so to sum it up. The biggest problem I see is the (non)independent
accounting. We simply cannot mix user+kernel limits otherwise we would
see issues (like kernel resource hog would force memcg-oom and innocent
members would die because their rss is much bigger).
It is also not clear to me what should happen when we hit the kmem
limit. I guess it will be kmem cache dependent.
So right now, tcp is completely independent, since it is not
accounted to kmem.
So why do we need kmem accounting when tcp (the only user at the moment)
doesn't use it?
Well, a bit historical. I needed a basic placeholder for it, since it
tcp is officially kmem. As the time passed, I took most of the stuff out
of this patch to leave just the basics I would need for tcp.
Turns out I ended up focusing on the rest, and some of the stuff was
left here.
At one point I merged tcp data into kmem, but then reverted this
behavior. the kmem counter stayed.
I agree deferring the whole behavior would be better.
quoted
In summary, we still never do non-independent accounting. When we
start doing it for the other caches, We will have to add a test at
charge time as well.
So we shouldn't do it as a part of this patchset because the further
usage is not clear and I think there will be some real issues with
user+kmem accounting (e.g. a proper memcg-oom implementation).
Can you just drop this patch?
Yes, but the whole set is in the net tree already. (All other patches
are tcp-related but this) Would you mind if I'd send a follow up patch
removing the kmem files, and leaving just the registration functions and
basic documentation? (And sorry for that as well in advance)
quoted
We still need to keep it separate though, in case the independent
flag is turned on/off
I don't mind to have kmem.tcp.* knobs.
--
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>
From: Michal Hocko <hidden> Date: 2011-12-16 13:30:59
On Fri 16-12-11 17:02:51, Glauber Costa wrote:
On 12/16/2011 04:32 PM, Michal Hocko wrote:
[...]
quoted
So why do we need kmem accounting when tcp (the only user at the moment)
doesn't use it?
Well, a bit historical. I needed a basic placeholder for it, since
it tcp is officially kmem. As the time passed, I took most of the
stuff out of this patch to leave just the basics I would need for
tcp.
Turns out I ended up focusing on the rest, and some of the stuff was
left here.
At one point I merged tcp data into kmem, but then reverted this
behavior. the kmem counter stayed.
I agree deferring the whole behavior would be better.
quoted
quoted
In summary, we still never do non-independent accounting. When we
start doing it for the other caches, We will have to add a test at
charge time as well.
So we shouldn't do it as a part of this patchset because the further
usage is not clear and I think there will be some real issues with
user+kmem accounting (e.g. a proper memcg-oom implementation).
Can you just drop this patch?
Yes, but the whole set is in the net tree already.
Isn't it only in some for-next branch? Can that one be updated?
(All other patches are tcp-related but this) Would you mind if I'd
send a follow up patch removing the kmem files, and leaving just the
registration functions and basic documentation? (And sorry for that as
well in advance)
Yes a followup patch would work as well.
--
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>
On Sun, Dec 11, 2011 at 11:47 PM, Glauber Costa [off-list ref] wrote:
+Memory limits as specified by the standard Memory Controller may or may not
+take kernel memory into consideration. This is achieved through the file
+memory.independent_kmem_limit. A Value different than 0 will allow for kernel
s/Value/value/
It is probably worth documenting the default value for
memory.independent_kmem_limit? I figure it would be zero at root and
and inherited from parents. But I think the implementation differs.
quoted hunk
@@ -277,6 +281,11 @@ struct mem_cgroup {
*/
unsigned long move_charge_at_immigrate;
/*
+ * Should kernel memory limits be stabilished independently
+ * from user memory ?
+ */
+ int kmem_independent_accounting;
I have no serious objection, but a full int seems like overkill for a
boolean value.
+static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
+{
+ int ret = 0;
+
+ ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
+ ARRAY_SIZE(kmem_cgroup_files));
+ return ret;
If you want to this function could be condensed down to:
return cgroup_add_files(...);
--
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>
From: Glauber Costa <hidden> Date: 2011-12-12 07:49:49
This patch introduces kmem.tcp.usage_in_bytes file, living in the
kmem_cgroup filesystem. It is a simple read-only file that displays the
amount of kernel memory currently consumed by the cgroup.
Signed-off-by: Glauber Costa <redacted>
Reviewed-by: Hiroyouki Kamezawa <redacted>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <redacted>
---
Documentation/cgroups/memory.txt | 1 +
net/ipv4/tcp_memcontrol.c | 21 +++++++++++++++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
@@ -79,6 +79,7 @@ Brief summary of control files. memory.independent_kmem_limit # select whether or not kernel memory limits are independent of user limits memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory+ memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation 1. History
--
1.7.6.4
--
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>
From: Glauber Costa <hidden> Date: 2011-12-12 07:50:34
This patch allows each namespace to independently set up
its levels for tcp memory pressure thresholds. This patch
alone does not buy much: we need to make this values
per group of process somehow. This is achieved in the
patches that follows in this patchset.
Signed-off-by: Glauber Costa <redacted>
Reviewed-by: KAMEZAWA Hiroyuki <redacted>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <redacted>
---
include/net/netns/ipv4.h | 1 +
include/net/tcp.h | 1 -
net/ipv4/af_inet.c | 2 +
net/ipv4/sysctl_net_ipv4.c | 51 +++++++++++++++++++++++++++++++++++++------
net/ipv4/tcp.c | 11 +-------
net/ipv4/tcp_ipv4.c | 1 -
net/ipv4/tcp_memcontrol.c | 9 +++++--
net/ipv6/af_inet6.c | 2 +
net/ipv6/tcp_ipv6.c | 1 -
9 files changed, 57 insertions(+), 22 deletions(-)
@@ -769,6 +800,12 @@ static __net_init int ipv4_sysctl_init_net(struct net *net)net->ipv4.sysctl_rt_cache_rebuild_count=4;+limit=nr_free_buffer_pages()/8;+limit=max(limit,128UL);+net->ipv4.sysctl_tcp_mem[0]=limit/4*3;+net->ipv4.sysctl_tcp_mem[1]=limit;+net->ipv4.sysctl_tcp_mem[2]=net->ipv4.sysctl_tcp_mem[0]*2;+net->ipv4.ipv4_hdr=register_net_sysctl_table(net,net_ipv4_ctl_path,table);if(net->ipv4.ipv4_hdr==NULL)
@@ -282,11 +282,9 @@ int sysctl_tcp_fin_timeout __read_mostly = TCP_FIN_TIMEOUT;structpercpu_countertcp_orphan_count;EXPORT_SYMBOL_GPL(tcp_orphan_count);-longsysctl_tcp_mem[3]__read_mostly;intsysctl_tcp_wmem[3]__read_mostly;intsysctl_tcp_rmem[3]__read_mostly;-EXPORT_SYMBOL(sysctl_tcp_mem);EXPORT_SYMBOL(sysctl_tcp_rmem);EXPORT_SYMBOL(sysctl_tcp_wmem);
@@ -3272,14 +3270,9 @@ void __init tcp_init(void)sysctl_tcp_max_orphans=cnt/2;sysctl_max_syn_backlog=max(128,cnt/256);-limit=nr_free_buffer_pages()/8;-limit=max(limit,128UL);-sysctl_tcp_mem[0]=limit/4*3;-sysctl_tcp_mem[1]=limit;-sysctl_tcp_mem[2]=sysctl_tcp_mem[0]*2;-/* Set per-socket limits to no more than 1/128 the pressure threshold */-limit=((unsignedlong)sysctl_tcp_mem[1])<<(PAGE_SHIFT-7);+limit=((unsignedlong)init_net.ipv4.sysctl_tcp_mem[1])+<<(PAGE_SHIFT-7);max_share=min(4UL*1024*1024,limit);sysctl_tcp_wmem[0]=SK_MEM_QUANTUM;
@@ -2216,7 +2216,6 @@ struct proto tcpv6_prot = {.memory_allocated=&tcp_memory_allocated,.memory_pressure=&tcp_memory_pressure,.orphan_count=&tcp_orphan_count,-.sysctl_mem=sysctl_tcp_mem,.sysctl_wmem=sysctl_tcp_wmem,.sysctl_rmem=sysctl_tcp_rmem,.max_header=MAX_TCP_HEADER,
--
1.7.6.4
--
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>
@@ -293,6 +293,8 @@ to trigger slab reclaim when those limits are reached. thresholds. The Memory Controller allows them to be controlled individually per cgroup, instead of globally.+* tcp memory pressure: sockets memory pressure for the tcp protocol.+ 3. User Interface 0. Configuration
@@ -0,0 +1,17 @@+#ifndef _TCP_MEMCG_H+#define _TCP_MEMCG_H++structtcp_memcontrol{+structcg_protocg_proto;+/* per-cgroup tcp memory pressure knobs */+structres_countertcp_memory_allocated;+structpercpu_countertcp_sockets_allocated;+/* those two are read-mostly, leave them at the end */+longtcp_prot_mem[3];+inttcp_memory_pressure;+};++structcg_proto*tcp_proto_cgroup(structmem_cgroup*memcg);+inttcp_init_cgroup(structcgroup*cgrp,structcgroup_subsys*ss);+voidtcp_destroy_cgroup(structcgroup*cgrp,structcgroup_subsys*ss);+#endif /* _TCP_MEMCG_H */
@@ -2258,9 +2298,6 @@ void sk_common_release(struct sock *sk)}EXPORT_SYMBOL(sk_common_release);-staticDEFINE_RWLOCK(proto_list_lock);-staticLIST_HEAD(proto_list);-#ifdef CONFIG_PROC_FS#define PROTO_INUSE_NR 64 /* should be enough for the first time */structprot_inuse{
@@ -1995,6 +1996,7 @@ static int tcp_v6_init_sock(struct sock *sk)sk->sk_rcvbuf=sysctl_tcp_rmem[1];local_bh_disable();+sock_update_memcg(sk);sk_sockets_allocated_inc(sk);local_bh_enable();
@@ -2228,6 +2230,9 @@ struct proto tcpv6_prot = {.compat_setsockopt=compat_tcp_setsockopt,.compat_getsockopt=compat_tcp_getsockopt,#endif+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM+.proto_cgroup=tcp_proto_cgroup,+#endif};staticconststructinet6_protocoltcpv6_protocol={
--
1.7.6.4
--
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>
From: David Miller <davem@davemloft.net> Date: 2011-12-13 00:08:00
From: Glauber Costa <redacted>
Date: Mon, 12 Dec 2011 11:47:00 +0400
This series fixes all the few comments raised in the last round,
and seem to have acquired consensus from the memcg side.
Dave, do you think it is acceptable now from the networking PoV?
In case positive, would you prefer merging this trough your tree,
or acking this so a cgroup maintainer can do it?
All applied to net-next, thanks.
--
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>
From: Christoph Paasch <hidden> Date: 2011-12-13 13:58:29
Hi,
On 12/13/2011 01:07 AM, David Miller wrote:
From: Glauber Costa <redacted>
Date: Mon, 12 Dec 2011 11:47:00 +0400
quoted
This series fixes all the few comments raised in the last round,
and seem to have acquired consensus from the memcg side.
Dave, do you think it is acceptable now from the networking PoV?
In case positive, would you prefer merging this trough your tree,
or acking this so a cgroup maintainer can do it?
All applied to net-next, thanks.
now there are plenty of compiler-warnings when CONFIG_CGROUPS is not set:
In file included from include/linux/tcp.h:211:0,
from include/linux/ipv6.h:221,
from include/net/ip_vs.h:23,
from kernel/sysctl_binary.c:6:
include/net/sock.h:67:57: warning: a??struct cgroup_subsysa?? declared
inside parameter list [enabled by default]
include/net/sock.h:67:57: warning: its scope is only this definition or
declaration, which is probably not what you want [enabled by default]
include/net/sock.h:67:57: warning: a??struct cgroupa?? declared inside
parameter list [enabled by default]
include/net/sock.h:68:61: warning: a??struct cgroup_subsysa?? declared
inside parameter list [enabled by default]
include/net/sock.h:68:61: warning: a??struct cgroupa?? declared inside
parameter list [enabled by default]
Because struct cgroup is only declared if CONFIG_CGROUPS is enabled.
(cfr. linux/cgroup.h)
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
UniversitA(C) Catholique de Louvain
--
--
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>
From: Eric Dumazet <hidden> Date: 2011-12-13 13:59:22
Le mardi 13 dA(C)cembre 2011 A 14:49 +0100, Christoph Paasch a A(C)crit :
now there are plenty of compiler-warnings when CONFIG_CGROUPS is not set:
In file included from include/linux/tcp.h:211:0,
from include/linux/ipv6.h:221,
from include/net/ip_vs.h:23,
from kernel/sysctl_binary.c:6:
include/net/sock.h:67:57: warning: a??struct cgroup_subsysa?? declared
inside parameter list [enabled by default]
include/net/sock.h:67:57: warning: its scope is only this definition or
declaration, which is probably not what you want [enabled by default]
include/net/sock.h:67:57: warning: a??struct cgroupa?? declared inside
parameter list [enabled by default]
include/net/sock.h:68:61: warning: a??struct cgroup_subsysa?? declared
inside parameter list [enabled by default]
include/net/sock.h:68:61: warning: a??struct cgroupa?? declared inside
parameter list [enabled by default]
Because struct cgroup is only declared if CONFIG_CGROUPS is enabled.
(cfr. linux/cgroup.h)
Yes, we probably need forward reference like this :
Thanks !
[PATCH net-next] net: fix build error if CONFIG_CGROUPS=n
Reported-by: Christoph Paasch <redacted>
Signed-off-by: Eric Dumazet <redacted>
---
include/net/sock.h | 2 ++
1 file changed, 2 insertions(+)
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>
From: David Miller <davem@davemloft.net> Date: 2011-12-13 18:47:29
From: Eric Dumazet <redacted>
Date: Tue, 13 Dec 2011 14:59:08 +0100
[PATCH net-next] net: fix build error if CONFIG_CGROUPS=n
Reported-by: Christoph Paasch <redacted>
Signed-off-by: Eric Dumazet <redacted>
Applied, thanks.
--
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>
From: Glauber Costa <hidden> Date: 2011-12-13 20:11:46
On 12/13/2011 05:59 PM, Eric Dumazet wrote:
Le mardi 13 décembre 2011 à 14:49 +0100, Christoph Paasch a écrit :
quoted
now there are plenty of compiler-warnings when CONFIG_CGROUPS is not set:
In file included from include/linux/tcp.h:211:0,
from include/linux/ipv6.h:221,
from include/net/ip_vs.h:23,
from kernel/sysctl_binary.c:6:
include/net/sock.h:67:57: warning: ‘struct cgroup_subsys’ declared
inside parameter list [enabled by default]
include/net/sock.h:67:57: warning: its scope is only this definition or
declaration, which is probably not what you want [enabled by default]
include/net/sock.h:67:57: warning: ‘struct cgroup’ declared inside
parameter list [enabled by default]
include/net/sock.h:68:61: warning: ‘struct cgroup_subsys’ declared
inside parameter list [enabled by default]
include/net/sock.h:68:61: warning: ‘struct cgroup’ declared inside
parameter list [enabled by default]
Because struct cgroup is only declared if CONFIG_CGROUPS is enabled.
(cfr. linux/cgroup.h)
Yes, we probably need forward reference like this :
Thanks !
[PATCH net-next] net: fix build error if CONFIG_CGROUPS=n
Reported-by: Christoph Paasch<redacted>
Signed-off-by: Eric Dumazet<redacted>
I am deeply sorry about that.
I was pretty sure I tested this case. But now that I looked into it, it
occurs to me that I may have tested it only with the Memory Cgroup
disabled, not with the master flag off.
Thanks for spotting this
--
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>
On Mon, 12 Dec 2011 11:47:00 +0400
Glauber Costa [off-list ref] wrote:
Hi,
This series fixes all the few comments raised in the last round,
and seem to have acquired consensus from the memcg side.
Dave, do you think it is acceptable now from the networking PoV?
In case positive, would you prefer merging this trough your tree,
or acking this so a cgroup maintainer can do it?
I met this bug at _1st_ run. Please enable _all_ debug options!.
From this log, your mem_cgroup_sockets_init() is totally buggy because
tcp init routine will call percpu_alloc() under read_lock.
please fix. I'll turn off the config for today's linux-next.
Regards,
-Kame
==
Dec 15 14:47:15 bluextal kernel: [ 228.386054] BUG: sleeping function called from invalid context at k
ernel/mutex.c:271
Dec 15 14:47:15 bluextal kernel: [ 228.386286] in_atomic(): 1, irqs_disabled(): 0, pid: 2692, name: cg
create
Dec 15 14:47:15 bluextal kernel: [ 228.386438] 4 locks held by cgcreate/2692:
Dec 15 14:47:15 bluextal kernel: [ 228.386580] #0: (&sb->s_type->i_mutex_key#15/1){+.+.+.}, at: [<ff
ffffff8118717e>] kern_path_create+0x8e/0x150
Dec 15 14:47:15 bluextal kernel: [ 228.387238] #1: (cgroup_mutex){+.+.+.}, at: [<ffffffff810c2907>]
cgroup_mkdir+0x77/0x3f0
Dec 15 14:47:15 bluextal kernel: [ 228.387755] #2: (&sb->s_type->i_mutex_key#15/2){+.+.+.}, at: [<ff
ffffff810be168>] cgroup_create_file+0xc8/0xf0
Dec 15 14:47:15 bluextal kernel: [ 228.388401] #3: (proto_list_lock){++++.+}, at: [<ffffffff814e7fe4
] mem_cgroup_sockets_init+0x24/0xf0
Dec 15 14:47:15 bluextal kernel: [ 228.388922] Pid: 2692, comm: cgcreate Not tainted 3.2.0-rc5-next-20
111214+ #34
Dec 15 14:47:15 bluextal kernel: [ 228.389154] Call Trace:
Dec 15 14:47:15 bluextal kernel: [ 228.389296] [<ffffffff81080f07>] __might_sleep+0x107/0x140
Dec 15 14:47:15 bluextal kernel: [ 228.389446] [<ffffffff815ce15f>] mutex_lock_nested+0x2f/0x50
Dec 15 14:47:15 bluextal kernel: [ 228.389597] [<ffffffff811354fd>] pcpu_alloc+0x4d/0xa20
Dec 15 14:47:15 bluextal kernel: [ 228.389745] [<ffffffff810a5759>] ? debug_check_no_locks_freed+0xa9/0x180
Dec 15 14:47:15 bluextal kernel: [ 228.389897] [<ffffffff810a5615>] ? trace_hardirqs_on_caller+0x105/0x190
Dec 15 14:47:15 bluextal kernel: [ 228.390057] [<ffffffff810a56ad>] ? trace_hardirqs_on+0xd/0x10
Dec 15 14:47:15 bluextal kernel: [ 228.390206] [<ffffffff810a3600>] ? lockdep_init_map+0x50/0x140
Dec 15 14:47:15 bluextal kernel: [ 228.390356] [<ffffffff81135f00>] __alloc_percpu+0x10/0x20
Dec 15 14:47:15 bluextal kernel: [ 228.390506] [<ffffffff812fda18>] __percpu_counter_init+0x58/0xc0
Dec 15 14:47:15 bluextal kernel: [ 228.390658] [<ffffffff8158fb26>] tcp_init_cgroup+0xd6/0x140
Dec 15 14:47:15 bluextal kernel: [ 228.390808] [<ffffffff814e8014>] mem_cgroup_sockets_init+0x54/0xf0
Dec 15 14:47:15 bluextal kernel: [ 228.390961] [<ffffffff8116b47b>] mem_cgroup_populate+0xab/0xc0
Dec 15 14:47:15 bluextal kernel: [ 228.391120] [<ffffffff810c053a>] cgroup_populate_dir+0x7a/0x110
Dec 15 14:47:15 bluextal kernel: [ 228.391271] [<ffffffff810c2b16>] cgroup_mkdir+0x286/0x3f0
Dec 15 14:47:15 bluextal kernel: [ 228.391420] [<ffffffff811836b4>] vfs_mkdir+0xa4/0xe0
Dec 15 14:47:15 bluextal kernel: [ 228.391566] [<ffffffff8118747d>] sys_mkdirat+0xcd/0xe0
Dec 15 14:47:15 bluextal kernel: [ 228.391714] [<ffffffff811874a8>] sys_mkdir+0x18/0x20
Dec 15 14:47:15 bluextal kernel: [ 228.391862] [<ffffffff815d86cf>] tracesys+0xdd/0xe2
==
--
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>
I met this bug at _1st_ run. Please enable _all_ debug options!.
Plus the CONFIG_NET=n and other build failures.
This patch series was seriously rushed, and very poorly handled.
Yet I kept getting so much pressure to review, comment upon, and
ultimately apply these patches. Never, ever, do this to me ever
again.
If I don't feel your patches are high priority enough or ready enough
for me to review, then TOO BAD. Don't ask people to pressure me or
get my attention. Instead, ask others for help and do testing before
wasting MY time and crapping up MY tree.
I should have noticed a red flag when I have James Bottomly asking me
to look at these patches, I should have pushed back. Instead, I
relented, and now I'm very seriously regretting it.
All the regressions in the net-next tree over the past several days
have been due to this patch set, and this patch set alone.
This code wasn't ready and needed, at a minimum, several more weeks of
work before being put in.
Instead, we're going to bandaid patch it up after the fact, rather
than just letting these changes mature naturally during the review
process.
--
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>
From: Glauber Costa <hidden> Date: 2011-12-15 06:49:10
On 12/15/2011 09:48 AM, David Miller wrote:
From: KAMEZAWA Hiroyuki<redacted>
Date: Thu, 15 Dec 2011 14:40:19 +0900
quoted
I met this bug at _1st_ run. Please enable _all_ debug options!.
Plus the CONFIG_NET=n and other build failures.
This patch series was seriously rushed, and very poorly handled.
Yet I kept getting so much pressure to review, comment upon, and
ultimately apply these patches. Never, ever, do this to me ever
again.
If I don't feel your patches are high priority enough or ready enough
for me to review, then TOO BAD. Don't ask people to pressure me or
get my attention. Instead, ask others for help and do testing before
wasting MY time and crapping up MY tree.
I should have noticed a red flag when I have James Bottomly asking me
to look at these patches, I should have pushed back. Instead, I
relented, and now I'm very seriously regretting it.
All the regressions in the net-next tree over the past several days
have been due to this patch set, and this patch set alone.
This code wasn't ready and needed, at a minimum, several more weeks of
work before being put in.
Instead, we're going to bandaid patch it up after the fact, rather
than just letting these changes mature naturally during the review
process.
Hi Dave,
You are right about all points. I will admit to it, face it, and
apologize it.
I guess the best I can do right now is fix whatever you guys point me to
and not repeat it in the future.
Thanks
--
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>