On 02/28/2012 08:31 PM, Suleiman Souhlal wrote:
On Tue, Feb 28, 2012 at 5:24 AM, Glauber Costaglom...@parallels.com wrote:
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
Introduce per-cgroup kmem_caches for memcg slab accounting, that
get created the first time we do an allocation of that
On 02/28/2012 08:07 PM, Suleiman Souhlal wrote:
On Tue, Feb 28, 2012 at 5:31 AM, Glauber Costaglom...@parallels.com wrote:
I don't fully understand this.
To me, the whole purpose of having a cache tied to a memcg, is that we know
all allocations from that particular cache should be billed to a
On 02/28/2012 08:36 PM, Suleiman Souhlal wrote:
On Tue, Feb 28, 2012 at 5:34 AM, Glauber Costaglom...@parallels.com wrote:
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
This config option dictates whether or not kernel memory in the
root cgroup should be accounted.
This may be useful in
On 02/22/2012 12:01 PM, Glauber Costa wrote:
On 02/22/2012 04:46 AM, KAMEZAWA Hiroyuki wrote:
On Tue, 21 Feb 2012 15:34:33 +0400
Glauber Costaglom...@parallels.com wrote:
Move some hardcoded definitions to an enum type.
Signed-off-by: Glauber Costaglom...@parallels.com
CC: Kirill
On 02/29/2012 09:10 PM, KAMEZAWA Hiroyuki wrote:
On Wed, 29 Feb 2012 11:09:50 -0800
Suleiman Souhlalsulei...@google.com wrote:
On Tue, Feb 28, 2012 at 10:00 PM, KAMEZAWA Hiroyuki
kamezawa.hir...@jp.fujitsu.com wrote:
On Mon, 27 Feb 2012 14:58:47 -0800
Suleiman Souhlalssouh...@freebsd.org
Hi,
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
This patch series introduces kernel memory accounting to memcg.
It currently only accounts for slab.
It's very similar to the patchset I sent back in October, but
with a number of fixes and improvements.
There is also overlap with Glauber's
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
Enabled with CONFIG_CGROUP_MEM_RES_CTLR_KMEM.
Adds the following files:
- memory.kmem.independent_kmem_limit
- memory.kmem.usage_in_bytes
- memory.kmem.limit_in_bytes
Signed-off-by: Suleiman Souhlalsulei...@google.com
---
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
Enabled with CONFIG_CGROUP_MEM_RES_CTLR_KMEM.
Adds the following files:
- memory.kmem.independent_kmem_limit
- memory.kmem.usage_in_bytes
- memory.kmem.limit_in_bytes
Signed-off-by: Suleiman Souhlalsulei...@google.com
---
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
Introduce per-cgroup kmem_caches for memcg slab accounting, that
get created the first time we do an allocation of that type in the
cgroup.
If we are not permitted to sleep in that allocation, the cache
gets created asynchronously.
And then we
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
From: Hugh Dickinshu...@google.com
If __mem_cgroup_try_charge() goes the bypass route in charging slab
(typically when the task has been OOM-killed), that later results in
res_counter_uncharge_locked() underflows - a stream of warnings from
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
This config option dictates whether or not kernel memory in the
root cgroup should be accounted.
This may be useful in an environment where everything is supposed to be
in a cgroup and accounted for. Large amounts of kernel memory in the
root
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
A later patch will also use this to move the accounting to the root
cgroup.
Suleiman,
Did you do any measurements to figure out how long does it take,
average, for dangling caches to go away ? Under memory pressure, let's say
On 02/23/2012 04:18 PM, Ying Han wrote:
On Tue, Feb 21, 2012 at 3:34 AM, Glauber Costaglom...@parallels.com wrote:
This is a first structured approach to tracking general kernel
memory within the memory controller. Please tell me what you think.
As previously proposed, one has the option of
As previously proposed, one has the option of keeping kernel memory
accounted separatedly, or together with the normal userspace memory.
However, this time I made the option to, in this later case, bill
the memory directly to memcg-res. It has the disadvantage that it becomes
complicated to know
On 02/22/2012 03:35 AM, Suleiman Souhlal wrote:
On Tue, Feb 21, 2012 at 3:34 AM, Glauber Costaglom...@parallels.com wrote:
@@ -5055,8 +5117,21 @@ int memcg_kmem_newpage(struct mem_cgroup *memcg, struct
page *page, unsigned lon
{
unsigned long size = pages PAGE_SHIFT;
On 02/22/2012 04:46 AM, KAMEZAWA Hiroyuki wrote:
On Tue, 21 Feb 2012 15:34:33 +0400
Glauber Costaglom...@parallels.com wrote:
Move some hardcoded definitions to an enum type.
Signed-off-by: Glauber Costaglom...@parallels.com
CC: Kirill A. Shutemovkir...@shutemov.name
CC: Greg
On 02/22/2012 03:50 AM, Suleiman Souhlal wrote:
On Tue, Feb 21, 2012 at 3:34 AM, Glauber Costaglom...@parallels.com wrote:
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 26fda11..2aa35b0 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
+struct kmem_cache *
+kmem_cache_dup(struct
On 02/22/2012 11:08 AM, Pekka Enberg wrote:
Hi Glauber,
On Tue, Feb 21, 2012 at 1:34 PM, Glauber Costaglom...@parallels.com wrote:
This is a first structured approach to tracking general kernel
memory within the memory controller. Please tell me what you think.
I like it! I only skimmed
On 02/22/2012 05:21 AM, KAMEZAWA Hiroyuki wrote:
On Tue, 21 Feb 2012 15:34:35 +0400
Glauber Costaglom...@parallels.com wrote:
This patch creates the infrastructure to allow us to register
per-memcg slab caches. As an example implementation, I am tracking
the dentry cache, but others will
On 02/22/2012 03:40 AM, Suleiman Souhlal wrote:
On Tue, Feb 21, 2012 at 3:34 AM, Glauber Costaglom...@parallels.com wrote:
In the context of tracking kernel memory objects to a cgroup, the
following problem appears: we may need to destroy a cgroup, but
this does not guarantee that all objects
On 02/22/2012 05:42 AM, KAMEZAWA Hiroyuki wrote:
On Tue, 21 Feb 2012 15:34:37 +0400
Glauber Costaglom...@parallels.com wrote:
This patch adds the shrinker interface to memcg proposed kmem
controller. With this, softlimits starts being meaningful. I didn't
played to much with softlimits
On 02/22/2012 05:25 AM, KAMEZAWA Hiroyuki wrote:
On Tue, 21 Feb 2012 15:34:36 +0400
Glauber Costaglom...@parallels.com wrote:
In the context of tracking kernel memory objects to a cgroup, the
following problem appears: we may need to destroy a cgroup, but
this does not guarantee that all
like to give it a try, you'll need one of Frederic's patches
that is used as a basis for this
(cgroups: ability to stop res charge propagation on bounded ancestor)
Glauber Costa (7):
small cleanup for memcontrol.c
Basic kernel memory functionality for the Memory Controller
per-cgroup slab
the Documentation files in this version, at least
in the first cycle. But they should not differ much from what
I posted previously. The patch itself is not much different
than the previous versions I posted.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Kirill A. Shutemov kir
Move some hardcoded definitions to an enum type.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Kirill A. Shutemov kir...@shutemov.name
CC: Greg Thelen gthe...@google.com
CC: Johannes Weiner jwei...@redhat.com
CC: Michal Hocko mho...@suse.cz
CC: Hiroyouki Kamezawa kamezawa.hir
.
This version is simpler, and serves to pave the way to future
work.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Kirill A. Shutemov kir...@shutemov.name
CC: Greg Thelen gthe...@google.com
CC: Johannes Weiner jwei...@redhat.com
CC: Michal Hocko mho...@suse.cz
CC: Hiroyouki Kamezawa kamezawa.hir
for the memcg case.
It also allows us to set the hard limit to a lower value than
current usage, as it is possible for the current memcg: a reclaim
is carried on, and if we succeed in freeing enough of kernel memory,
we can lower the limit.
Signed-off-by: Glauber Costa glom...@parallels.com
CC
will be serviced from
the new cache.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Kirill A. Shutemov kir...@shutemov.name
CC: Greg Thelen gthe...@google.com
CC: Johannes Weiner jwei...@redhat.com
CC: Michal Hocko mho...@suse.cz
CC: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com
CC: Paul Turner
On 02/15/2012 02:31 AM, Serge Hallyn wrote:
Quoting Glauber Costa (glom...@parallels.com):
On 02/02/2012 06:19 PM, Glauber Costa wrote:
Hi,
Here is my new attempt to get a per-container version of some
/proc data such as /proc/stat and /proc/uptime.
In this series I solved the visibility
On 02/02/2012 06:19 PM, Glauber Costa wrote:
Hi,
Here is my new attempt to get a per-container version of some
/proc data such as /proc/stat and /proc/uptime.
In this series I solved the visibility problem, which is,
the problem of how and when to show /proc/stat data per-cgroup,
by declaring
In this patchset, I am exposing other data as ticks as well,
that are originally nanoseconds. Whether or not I should do it,
it is open for debate, and I am happy to drop this patch if we
decide not to. But right now this exists to support the
further patch that uses it.
Signed-off-by: Glauber
the general direction to be working, and would like to know
what you think.
Thanks
Glauber Costa (5):
make steal time's to-tick routine generic
store number of iowait events in a task_group
account guest time per-cgroup as well.
expose fine-grained per-cpu data for cpuacct stats
expose per
Instead of just having the rq to hold them, this patch stores
the nr_iowait figures for each task_group, except for the root
task group. That one is kept using the numbers originating from
the rq.
Signed-off-by: Glauber Costa glom...@parallels.com
---
include/linux/sched.h |1 +
kernel/sched
We already track multiple tick statistics per-cgroup, using
the task_group_account_field facility. This patch accounts
guest_time in that manner as well.
Signed-off-by: Glauber Costa glom...@parallels.com
---
kernel/sched/core.c | 10 --
1 files changed, 4 insertions(+), 6 deletions
to show any units
you guys would prefer.
Signed-off-by: Glauber Costa glom...@parallels.com
---
kernel/sched/core.c | 114 ++
kernel/sched/fair.c | 45
kernel/sched/sched.h |3 +
3 files changed, 162 insertions(+), 0
you guys would prefer.
Signed-off-by: Glauber Costa glom...@parallels.com
---
kernel/sched/core.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 91ea913..013ca9c 100644
--- a/kernel/sched/core.c
On 12/23/2011 01:10 AM, Jason Baron wrote:
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
On 12/12/2011 01:31 PM, Glauber Costa wrote:
In commit a25cac5198 we changed the way we calculate idle and iowait
for /proc/stat displaying purposes. However, this same information
is also displayed in /proc/uptime. These values can now be inconsistent.
So I propose we draw both idle values
On 12/23/2011 05:39 PM, Michal Hocko wrote:
On Fri 23-12-11 14:08:09, Glauber Costa wrote:
On 12/12/2011 01:31 PM, Glauber Costa wrote:
In commit a25cac5198 we changed the way we calculate idle and iowait
for /proc/stat displaying purposes. However, this same information
is also displayed
in the struct, since it was not provided before.
Please let me know what you guys think of this.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Paul Turner p...@google.com
CC: Li Zefan l...@cn.fujitsu.com
CC: Peter Zijlstra a.p.zijls...@chello.nl
---
kernel/sched/core.c | 198
On 12/20/2011 03:14 PM, Stanislav Kinsbursky wrote:
Service transports are parametrized by network namespace. And thus lookup of
transport instance have to take network namespace into account.
Signed-off-by: Stanislav Kinsburskyskinsbur...@parallels.com
---
fs/lockd/svc.c |
On 12/19/2011 11:58 AM, Li Zefan wrote:
Glauber Costa wrote:
Turns out that most of the infrastructure we need to put two controllers in the
same hierarchy is by far already into place. All we need to do is not failing
when we specify two of them.
You don't need to change anything to mount
,
Please let me know if this is tuned with the idea you had in mind.
If this is okay, I patch that extracts usage from cpu cgroup data
in case of comount would follow.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Paul Turner p...@google.com
CC: Li Zefan l...@cn.fujitsu.com
---
kernel
On 12/16/2011 04:32 PM, Michal Hocko wrote:
On Thu 15-12-11 16:29:18, Glauber Costa wrote:
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:
[...]
@@ -3848,10 +3862,17 @@ static inline u64 mem_cgroup_usage
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:
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
On 12/15/2011 09:48 AM, David Miller wrote:
From: KAMEZAWA Hiroyukikamezawa.hir...@jp.fujitsu.com
Date: Thu, 15 Dec 2011 14:40:19 +0900
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,
On 12/14/2011 10:18 PM, Tejun Heo wrote:
Hello,
On Wed, Dec 14, 2011 at 11:09:14AM +0400, Glauber Costa wrote:
That's indeed confusing, and it comes from the fact that we always
inherit clone_children from the parent - which is sane, IMHO. So
this flag only has any value in establishing
On 12/13/2011 01:02 PM, Stanislav Kinsbursky wrote:
13.12.2011 02:52, Andrew Morton пишет:
On Mon, 12 Dec 2011 21:50:00 +0300
Stanislav Kinsburskyskinsbur...@parallels.com wrote:
This routine is required for SUNRPC sysctl's, which are going to be
allocated,
processed and destroyed per network
On 12/13/2011 02:03 PM, Kinsbursky Stanislav wrote:
13.12.2011 13:13, Glauber Costa пишет:
On 12/13/2011 01:02 PM, Stanislav Kinsbursky wrote:
13.12.2011 02:52, Andrew Morton пишет:
On Mon, 12 Dec 2011 21:50:00 +0300
Stanislav Kinsburskyskinsbur...@parallels.com wrote:
This routine
On 12/13/2011 05:59 PM, Eric Dumazet wrote:
Le mardi 13 décembre 2011 à 14:49 +0100, Christoph Paasch a é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,
On 12/14/2011 06:29 AM, Li Zefan wrote:
Tejun Heo wrote:
On Sun, Dec 11, 2011 at 03:45:37PM +0100, Glauber Costa wrote:
There is no reason to have a flags field, and then a separate
bool field just to indicate if the clone_children flag is set.
Make it a flag
Signed-off-by: Glauber Costaglom
On 12/12/2011 11:06 AM, Glauber Costa wrote:
On 12/12/2011 04:31 AM, KAMEZAWA Hiroyuki wrote:
On Sun, 11 Dec 2011 15:50:56 +0100
Glauber Costaglom...@parallels.com wrote:
On 12/09/2011 03:55 PM, Glauber Costa wrote:
On 12/09/2011 12:03 PM, Peter Zijlstra wrote:
On Mon, 2011-12-05 at 07:32
On 12/12/2011 01:33 PM, Peter Zijlstra wrote:
On Fri, 2011-12-09 at 12:55 -0200, Glauber Costa wrote:
On 12/09/2011 12:03 PM, Peter Zijlstra wrote:
Namespaces seem to be about limiting visibility, cgroups about
controlling resources.
The two things are hopelessly disjoint atm, but I believe
On 12/11/2011 03:45 PM, Glauber Costa wrote:
There is no reason to have a flags field, and then a separate
bool field just to indicate if the clone_children flag is set.
Make it a flag
Signed-off-by: Glauber Costaglom...@parallels.com
This one is repeated, I don't know how it went through
Hi,
While hacking on other stuff I found these spots that could
receive some simple cleanup in cgroup.c. Nothing revolutionary.
Patch 1 is rather trivial, the other 2 are more of a matter of
taste I'd say, but I believe we'd be better of this way.
Glauber Costa (3):
nitpick: make simple
There is no reason to have a flags field, and then a separate
bool field just to indicate if the clone_children flag is set.
Make it a flag
Signed-off-by: Glauber Costa glom...@parallels.com
---
kernel/cgroup.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel
Those are quite simple bit-testing functions that are
only used within this file. Not reason for them not to
be inline.
Signed-off-by: Glauber Costa glom...@parallels.com
---
kernel/cgroup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel
There is no reason to have a flags field, and then a separate
bool field just to indicate if the clone_children flag is set.
Make it a flag
Signed-off-by: Glauber Costa glom...@parallels.com
---
kernel/cgroup.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel
There is no reason to have a flags field, and then a separate
bool field just to indicate if 'none' subsystem were explicitly
requested.
Make it a flag
Signed-off-by: Glauber Costa glom...@parallels.com
---
kernel/cgroup.c | 20
1 files changed, 12 insertions(+), 8
On 12/09/2011 03:55 PM, Glauber Costa wrote:
On 12/09/2011 12:03 PM, Peter Zijlstra wrote:
On Mon, 2011-12-05 at 07:32 -0200, Glauber Costa wrote:
Hi,
Specially Peter and Paul, but all the others:
As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer
On 12/11/2011 07:55 PM, KOSAKI Motohiro wrote:
-static int notify_on_release(const struct cgroup *cgrp)
+static inline int notify_on_release(const struct cgroup *cgrp)
{
return test_bit(CGRP_NOTIFY_ON_RELEASE,cgrp-flags);
}
-static int clone_children(const struct cgroup *cgrp)
On 12/11/2011 08:11 PM, KOSAKI Motohiro wrote:
IOW a /proc namespace coupled to cgroup scope would do what you want.
Now my head hurts..
Mine too. The idea is good, but too broad. Boils down to: How do you
couple them? And none of the methods I thought about seemed to make any
sense.
If we
On 12/12/2011 04:31 AM, KAMEZAWA Hiroyuki wrote:
On Sun, 11 Dec 2011 15:50:56 +0100
Glauber Costaglom...@parallels.com wrote:
On 12/09/2011 03:55 PM, Glauber Costa wrote:
On 12/09/2011 12:03 PM, Peter Zijlstra wrote:
On Mon, 2011-12-05 at 07:32 -0200, Glauber Costa wrote:
Hi,
Specially
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
here, no performance impact at all is
expected in the case where we don't have cgroups disabled.
Signed-off-by: Glauber Costa glom...@parallels.com
Reviewed-by: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com
CC: David S. Miller da...@davemloft.net
CC: Eric W. Biederman ebied...@xmission.com
CC
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 glom
-by: Glauber Costa glom...@parallels.com
CC: Kirill A. Shutemov kir...@shutemov.name
CC: Paul Menage p...@paulmenage.org
CC: Greg Thelen gthe...@google.com
CC: Johannes Weiner jwei...@redhat.com
CC: Michal Hocko mho...@suse.cz
---
Documentation/cgroups/memory.txt | 40 ++-
init/Kconfig
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 glom...@parallels.com
Reviewed
This patch introduces memory pressure controls for the tcp
protocol. It uses the generic socket memory pressure code
introduced in earlier patches, and fills in the
necessary data in cg_proto struct.
Signed-off-by: Glauber Costa glom...@parallels.com
Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir
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 glom...@parallels.com
Reviewed-by: Hiroyouki Kamezawa kamezawa.hir
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 glom...@parallels.com
Reviewed-by: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com
CC: David S. Miller da
the maximum memory ever used by this cgroup.
Signed-off-by: Glauber Costa glom...@parallels.com
Reviewed-by: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com
CC: David S. Miller da...@davemloft.net
CC: Eric W. Biederman ebied...@xmission.com
---
net/ipv4/tcp_memcontrol.c | 12 +++-
1 files
On 12/08/2011 11:21 PM, KAMEZAWA Hiroyuki wrote:
On Mon, 5 Dec 2011 19:34:55 -0200
Glauber Costaglom...@parallels.com 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:
*
On 12/08/2011 11:21 PM, KAMEZAWA Hiroyuki wrote:
Hm, why you check val != parent-kmem_independent_accounting ?
if (parent parent-use_hierarchy)
return -EINVAL;
?
BTW, you didn't check this cgroup has children or not.
I think
if (this_cgroup-use_hierarchy
On 12/09/2011 12:44 PM, David Laight wrote:
How about this?
val = !!val;
/*
* This follows the same hierarchy restrictions than
* mem_cgroup_hierarchy_write()
*/
if (!parent || !parent-use_hierarchy) {
if
On 12/09/2011 12:03 PM, Peter Zijlstra wrote:
On Mon, 2011-12-05 at 07:32 -0200, Glauber Costa wrote:
Hi,
Specially Peter and Paul, but all the others:
As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer
to that, there is a question - one I've asked before but without
On 12/05/2011 07:34 PM, Glauber Costa wrote:
Hi,
This is my new attempt to fix all the concerns that were raised during
the last iteration.
I should highlight:
1) proc information is kept intact. (although I kept the wrapper functions)
it will be submitted as a follow up patch so it can
On 12/04/2011 11:59 PM, KAMEZAWA Hiroyuki wrote:
On Fri, 2 Dec 2011 15:46:46 -0200
Glauber Costaglom...@parallels.com wrote:
static void proto_seq_printf(struct seq_file *seq, struct proto *proto)
{
+ struct mem_cgroup *memcg = mem_cgroup_from_task(current);
+
On 12/05/2011 12:06 AM, KAMEZAWA Hiroyuki wrote:
On Fri, 2 Dec 2011 16:04:08 -0200
Glauber Costaglom...@parallels.com wrote:
On 11/30/2011 12:11 AM, KAMEZAWA Hiroyuki wrote:
On Tue, 29 Nov 2011 21:56:51 -0200
Glauber Costaglom...@parallels.com wrote:
Hi,
This patchset implements
On 12/05/2011 12:18 AM, KAMEZAWA Hiroyuki wrote:
On Fri, 2 Dec 2011 16:11:56 -0200
Glauber Costaglom...@parallels.com wrote:
On 11/30/2011 12:22 AM, KAMEZAWA Hiroyuki wrote:
On Tue, 29 Nov 2011 21:57:01 -0200
Glauber Costaglom...@parallels.com wrote:
Since this code is still
Hi,
Specially Peter and Paul, but all the others:
As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer
to that, there is a question - one I've asked before but without that
much of an audience - of whether /proc files read from process living on
cgroups should display
On 12/05/2011 07:51 AM, KAMEZAWA Hiroyuki wrote:
On Mon, 5 Dec 2011 07:09:51 -0200
Glauber Costaglom...@parallels.com wrote:
On 12/05/2011 12:06 AM, KAMEZAWA Hiroyuki wrote:
On Fri, 2 Dec 2011 16:04:08 -0200
Glauber Costaglom...@parallels.com wrote:
On 11/30/2011 12:11 AM, KAMEZAWA
pointer (which is cleaner anyway)
The rest should be mostly the same except for small fixes and style changes.
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
here, no performance impact at all is
expected in the case where we don't have cgroups disabled.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: David S. Miller da...@davemloft.net
CC: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com
CC: Eric W. Biederman ebied...@xmission.com
CC: Eric
-by: Glauber Costa glom...@parallels.com
Reviewed-by: Kirill A. Shutemov kir...@shutemov.name
CC: Paul Menage p...@paulmenage.org
CC: Greg Thelen gthe...@google.com
---
Documentation/cgroups/memory.txt | 40 ++-
init/Kconfig | 11
mm/memcontrol.c
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 glom...@parallels.com
CC: Kirill
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 glom
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 glom...@parallels.com
CC: David S. Miller da...@davemloft.net
CC: Hiroyouki Kamezawa kamezawa.hir
the maximum memory ever used by this cgroup.
Signed-off-by: Glauber Costa glom...@parallels.com
Reviewed-by: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com
CC: David S. Miller da...@davemloft.net
CC: Eric W. Biederman ebied...@xmission.com
---
net/ipv4/tcp_memcontrol.c | 12 +++-
1 files
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 glom...@parallels.com
Reviewed-by: Hiroyouki Kamezawa kamezawa.hir
-by: Glauber Costa glom...@parallels.com
Reviewed-by: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com
CC: David S. Miller da...@davemloft.net
CC: Eric W. Biederman ebied...@xmission.com
---
net/ipv4/tcp_memcontrol.c | 31 +++
1 files changed, 31 insertions(+), 0
This patch introduces memory pressure controls for the tcp
protocol. It uses the generic socket memory pressure code
introduced in earlier patches, and fills in the
necessary data in cg_proto struct.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: KAMEZAWA Hiroyuki kamezawa.hir
On 12/05/2011 10:05 PM, KAMEZAWA Hiroyuki wrote:
On Mon, 5 Dec 2011 07:32:33 -0200
Glauber Costaglom...@parallels.com wrote:
Hi,
Specially Peter and Paul, but all the others:
As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer
to that, there is a question - one I've
static void proto_seq_printf(struct seq_file *seq, struct proto *proto)
{
+ struct mem_cgroup *memcg = mem_cgroup_from_task(current);
+
seq_printf(seq, %-9s %4u %6d %6ld %-3s %6u %-3s %-10s
%2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c
On 11/29/2011 11:49 PM, KAMEZAWA Hiroyuki wrote:
-static struct mem_cgroup *mem_cgroup_from_cont(struct cgroup *cont)
+struct mem_cgroup *mem_cgroup_from_cont(struct cgroup *cont)
{
return container_of(cgroup_subsys_state(cont,
mem_cgroup_subsys_id),
On 11/30/2011 12:11 AM, KAMEZAWA Hiroyuki wrote:
On Tue, 29 Nov 2011 21:56:51 -0200
Glauber Costaglom...@parallels.com wrote:
Hi,
This patchset implements per-cgroup tcp memory pressure controls. It did not
change
significantly since last submission: rather, it just merges the comments Kame
On 11/30/2011 12:22 AM, KAMEZAWA Hiroyuki wrote:
On Tue, 29 Nov 2011 21:57:01 -0200
Glauber Costaglom...@parallels.com wrote:
Since this code is still experimental, we are leaving the exact
details of how to move tasks between cgroups when kernel memory
accounting is used as future work.
For
On 11/28/2011 12:55 AM, KAMEZAWA Hiroyuki wrote:
On Fri, 25 Nov 2011 15:38:08 -0200
Glauber Costaglom...@parallels.com wrote:
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
know if there is anything else I should address.
Glauber Costa (10):
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
here, no performance impact at all is
expected in the case where we don't have cgroups disabled.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: David S. Miller da...@davemloft.net
CC: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com
CC: Eric W. Biederman ebied...@xmission.com
CC: Eric
801 - 900 of 979 matches
Mail list logo
