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 Costa
This one is repeated, I don't know how it went through. Sorry.
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 functio
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
---
kernel/cgroup.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgro
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
---
kernel/cgroup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index d9d5648..e4
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
---
kernel/cgroup.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgro
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
---
kernel/cgroup.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/k
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
to that, there is a ques
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 c
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 r
On Sun, 11 Dec 2011 15:50:56 +0100
Glauber Costa 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 Peter and Paul, but all the others:
> >>>
> >>> As
On Fri, 9 Dec 2011 10:43:00 -0200
Glauber Costa wrote:
> On 12/09/2011 12:05 AM, KAMEZAWA Hiroyuki wrote:
> > On Mon, 5 Dec 2011 19:34:57 -0200
> > Glauber Costa wrote:
> >
> >> The goal of this work is to move the memory pressure tcp
> >> controls to a cgroup, instead of just relying on global
On Fri, 9 Dec 2011 12:37:23 -0200
Glauber Costa wrote:
> 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 cg
On 12/12/2011 04:31 AM, KAMEZAWA Hiroyuki wrote:
On Sun, 11 Dec 2011 15:50:56 +0100
Glauber Costa 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 Peter and Paul, but all
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 ca
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 he
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
Reviewe
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: Glau
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
unt
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
Reviewed-by: KAMEZAWA Hiroyuki
CC: Eric W. Biederman
---
Document
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
Reviewed-by: Hiroyouki Kamezawa
CC: David S. Miller
CC: Eric W. Bieder
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
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-
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
23 matches
Mail list logo
