From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org,
lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org,
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org,
avagin-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
KAMEZAWA Hiroyuki
<kamezawa.hiroyu-LdfC7J4mv27QFUHtdCDX3A@public.gmane.org>
Subject: Re: [PATCH v7 04/10] tcp memory pressure controls
Date: Fri, 2 Dec 2011 15:57:28 -0200 [thread overview]
Message-ID: <4ED91188.6030503@parallels.com> (raw)
In-Reply-To: <20111130104943.d9b210ee.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
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), struct mem_cgroup,
>> @@ -4717,14 +4732,27 @@ static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>>
>> ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
>> ARRAY_SIZE(kmem_cgroup_files));
>> +
>> + if (!ret)
>> + ret = mem_cgroup_sockets_init(cont, ss);
>> return ret;
>> };
>
> You does initizalication here. The reason what I think is
> 1. 'proto_list' is not available at createion of root cgroup and
> you need to delay set up until mounting.
>
> If so, please add comment or find another way.
> This seems not very clean to me.
Yes, we do can run into some ordering issues. A part of the
initialization can be done earlier. But I preferred to move it all later
instead of creating two functions for it. But I can change that if you
want, no big deal.
>
>
>
>
>> +static DEFINE_RWLOCK(proto_list_lock);
>> +static LIST_HEAD(proto_list);
>> +
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss)
>> +{
>> + struct proto *proto;
>> + int ret = 0;
>> +
>> + read_lock(&proto_list_lock);
>> + list_for_each_entry(proto,&proto_list, node) {
>> + if (proto->init_cgroup)
>> + ret = proto->init_cgroup(cgrp, ss);
>> + if (ret)
>> + goto out;
>> + }
>
> seems indent is bad or {} is missing.
>
Thanks. I'll rewrite it, since I did miss {} around the first if. But no
test could possibly catch it, since what I wanted to write, and what I
wrote by mistake end up being equivalent.
>> +EXPORT_SYMBOL(memcg_tcp_enter_memory_pressure);
>> +
>> +int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
>> +{
>> + /*
>> + * The root cgroup does not use res_counters, but rather,
>> + * rely on the data already collected by the network
>> + * subsystem
>> + */
>> + struct res_counter *res_parent = NULL;
>> + struct cg_proto *cg_proto;
>> + struct tcp_memcontrol *tcp;
>> + struct mem_cgroup *memcg = mem_cgroup_from_cont(cgrp);
>> + struct mem_cgroup *parent = parent_mem_cgroup(memcg);
>> +
>> + cg_proto = tcp_prot.proto_cgroup(memcg);
>> + if (!cg_proto)
>> + return 0;
>> +
>> + tcp = tcp_from_cgproto(cg_proto);
>> + cg_proto->parent = tcp_prot.proto_cgroup(parent);
>> +
>> + tcp->tcp_prot_mem[0] = sysctl_tcp_mem[0];
>> + tcp->tcp_prot_mem[1] = sysctl_tcp_mem[1];
>> + tcp->tcp_prot_mem[2] = sysctl_tcp_mem[2];
>> + tcp->tcp_memory_pressure = 0;
>
> Question:
>
> Is this value will be updated when an admin chages sysctl ?
yes.
> I guess, this value is set at system init script or some which may
> happen later than mounting cgroup.
> I don't like to write a guideline 'please set sysctl val before
> mounting cgroup'
Agreed.
This code is in patch 6 (together with the limiting):
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
+ rcu_read_lock();
+ memcg = mem_cgroup_from_task(current);
+
+ tcp_prot_mem(memcg, vec[0], 0);
+ tcp_prot_mem(memcg, vec[1], 1);
+ tcp_prot_mem(memcg, vec[2], 2);
+ rcu_read_unlock();
+#endif
tcp_prot_mem is just a wrapper around the assignment so we can access
memcg's inner fields.
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, paul@paulmenage.org,
lizf@cn.fujitsu.com, ebiederm@xmission.com, davem@davemloft.net,
gthelen@google.com, netdev@vger.kernel.org, linux-mm@kvack.org,
kirill@shutemov.name, avagin@parallels.com, devel@openvz.org,
eric.dumazet@gmail.com, cgroups@vger.kernel.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujtisu.com>
Subject: Re: [PATCH v7 04/10] tcp memory pressure controls
Date: Fri, 2 Dec 2011 15:57:28 -0200 [thread overview]
Message-ID: <4ED91188.6030503@parallels.com> (raw)
In-Reply-To: <20111130104943.d9b210ee.kamezawa.hiroyu@jp.fujitsu.com>
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), struct mem_cgroup,
>> @@ -4717,14 +4732,27 @@ static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>>
>> ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
>> ARRAY_SIZE(kmem_cgroup_files));
>> +
>> + if (!ret)
>> + ret = mem_cgroup_sockets_init(cont, ss);
>> return ret;
>> };
>
> You does initizalication here. The reason what I think is
> 1. 'proto_list' is not available at createion of root cgroup and
> you need to delay set up until mounting.
>
> If so, please add comment or find another way.
> This seems not very clean to me.
Yes, we do can run into some ordering issues. A part of the
initialization can be done earlier. But I preferred to move it all later
instead of creating two functions for it. But I can change that if you
want, no big deal.
>
>
>
>
>> +static DEFINE_RWLOCK(proto_list_lock);
>> +static LIST_HEAD(proto_list);
>> +
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss)
>> +{
>> + struct proto *proto;
>> + int ret = 0;
>> +
>> + read_lock(&proto_list_lock);
>> + list_for_each_entry(proto,&proto_list, node) {
>> + if (proto->init_cgroup)
>> + ret = proto->init_cgroup(cgrp, ss);
>> + if (ret)
>> + goto out;
>> + }
>
> seems indent is bad or {} is missing.
>
Thanks. I'll rewrite it, since I did miss {} around the first if. But no
test could possibly catch it, since what I wanted to write, and what I
wrote by mistake end up being equivalent.
>> +EXPORT_SYMBOL(memcg_tcp_enter_memory_pressure);
>> +
>> +int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
>> +{
>> + /*
>> + * The root cgroup does not use res_counters, but rather,
>> + * rely on the data already collected by the network
>> + * subsystem
>> + */
>> + struct res_counter *res_parent = NULL;
>> + struct cg_proto *cg_proto;
>> + struct tcp_memcontrol *tcp;
>> + struct mem_cgroup *memcg = mem_cgroup_from_cont(cgrp);
>> + struct mem_cgroup *parent = parent_mem_cgroup(memcg);
>> +
>> + cg_proto = tcp_prot.proto_cgroup(memcg);
>> + if (!cg_proto)
>> + return 0;
>> +
>> + tcp = tcp_from_cgproto(cg_proto);
>> + cg_proto->parent = tcp_prot.proto_cgroup(parent);
>> +
>> + tcp->tcp_prot_mem[0] = sysctl_tcp_mem[0];
>> + tcp->tcp_prot_mem[1] = sysctl_tcp_mem[1];
>> + tcp->tcp_prot_mem[2] = sysctl_tcp_mem[2];
>> + tcp->tcp_memory_pressure = 0;
>
> Question:
>
> Is this value will be updated when an admin chages sysctl ?
yes.
> I guess, this value is set at system init script or some which may
> happen later than mounting cgroup.
> I don't like to write a guideline 'please set sysctl val before
> mounting cgroup'
Agreed.
This code is in patch 6 (together with the limiting):
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
+ rcu_read_lock();
+ memcg = mem_cgroup_from_task(current);
+
+ tcp_prot_mem(memcg, vec[0], 0);
+ tcp_prot_mem(memcg, vec[1], 1);
+ tcp_prot_mem(memcg, vec[2], 2);
+ rcu_read_unlock();
+#endif
tcp_prot_mem is just a wrapper around the assignment so we can access
memcg's inner fields.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <linux-kernel@vger.kernel.org>, <paul@paulmenage.org>,
<lizf@cn.fujitsu.com>, <ebiederm@xmission.com>,
<davem@davemloft.net>, <gthelen@google.com>,
<netdev@vger.kernel.org>, <linux-mm@kvack.org>,
<kirill@shutemov.name>, <avagin@parallels.com>,
<devel@openvz.org>, <eric.dumazet@gmail.com>,
<cgroups@vger.kernel.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujtisu.com>
Subject: Re: [PATCH v7 04/10] tcp memory pressure controls
Date: Fri, 2 Dec 2011 15:57:28 -0200 [thread overview]
Message-ID: <4ED91188.6030503@parallels.com> (raw)
In-Reply-To: <20111130104943.d9b210ee.kamezawa.hiroyu@jp.fujitsu.com>
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), struct mem_cgroup,
>> @@ -4717,14 +4732,27 @@ static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>>
>> ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
>> ARRAY_SIZE(kmem_cgroup_files));
>> +
>> + if (!ret)
>> + ret = mem_cgroup_sockets_init(cont, ss);
>> return ret;
>> };
>
> You does initizalication here. The reason what I think is
> 1. 'proto_list' is not available at createion of root cgroup and
> you need to delay set up until mounting.
>
> If so, please add comment or find another way.
> This seems not very clean to me.
Yes, we do can run into some ordering issues. A part of the
initialization can be done earlier. But I preferred to move it all later
instead of creating two functions for it. But I can change that if you
want, no big deal.
>
>
>
>
>> +static DEFINE_RWLOCK(proto_list_lock);
>> +static LIST_HEAD(proto_list);
>> +
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss)
>> +{
>> + struct proto *proto;
>> + int ret = 0;
>> +
>> + read_lock(&proto_list_lock);
>> + list_for_each_entry(proto,&proto_list, node) {
>> + if (proto->init_cgroup)
>> + ret = proto->init_cgroup(cgrp, ss);
>> + if (ret)
>> + goto out;
>> + }
>
> seems indent is bad or {} is missing.
>
Thanks. I'll rewrite it, since I did miss {} around the first if. But no
test could possibly catch it, since what I wanted to write, and what I
wrote by mistake end up being equivalent.
>> +EXPORT_SYMBOL(memcg_tcp_enter_memory_pressure);
>> +
>> +int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
>> +{
>> + /*
>> + * The root cgroup does not use res_counters, but rather,
>> + * rely on the data already collected by the network
>> + * subsystem
>> + */
>> + struct res_counter *res_parent = NULL;
>> + struct cg_proto *cg_proto;
>> + struct tcp_memcontrol *tcp;
>> + struct mem_cgroup *memcg = mem_cgroup_from_cont(cgrp);
>> + struct mem_cgroup *parent = parent_mem_cgroup(memcg);
>> +
>> + cg_proto = tcp_prot.proto_cgroup(memcg);
>> + if (!cg_proto)
>> + return 0;
>> +
>> + tcp = tcp_from_cgproto(cg_proto);
>> + cg_proto->parent = tcp_prot.proto_cgroup(parent);
>> +
>> + tcp->tcp_prot_mem[0] = sysctl_tcp_mem[0];
>> + tcp->tcp_prot_mem[1] = sysctl_tcp_mem[1];
>> + tcp->tcp_prot_mem[2] = sysctl_tcp_mem[2];
>> + tcp->tcp_memory_pressure = 0;
>
> Question:
>
> Is this value will be updated when an admin chages sysctl ?
yes.
> I guess, this value is set at system init script or some which may
> happen later than mounting cgroup.
> I don't like to write a guideline 'please set sysctl val before
> mounting cgroup'
Agreed.
This code is in patch 6 (together with the limiting):
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
+ rcu_read_lock();
+ memcg = mem_cgroup_from_task(current);
+
+ tcp_prot_mem(memcg, vec[0], 0);
+ tcp_prot_mem(memcg, vec[1], 1);
+ tcp_prot_mem(memcg, vec[2], 2);
+ rcu_read_unlock();
+#endif
tcp_prot_mem is just a wrapper around the assignment so we can access
memcg's inner fields.
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Cc: <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org>,
<lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>,
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
<gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
<kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>,
<avagin-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
<devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
<cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
KAMEZAWA Hiroyuki
<kamezawa.hiroyu-LdfC7J4mv27QFUHtdCDX3A@public.gmane.org>
Subject: Re: [PATCH v7 04/10] tcp memory pressure controls
Date: Fri, 2 Dec 2011 15:57:28 -0200 [thread overview]
Message-ID: <4ED91188.6030503@parallels.com> (raw)
In-Reply-To: <20111130104943.d9b210ee.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
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), struct mem_cgroup,
>> @@ -4717,14 +4732,27 @@ static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>>
>> ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
>> ARRAY_SIZE(kmem_cgroup_files));
>> +
>> + if (!ret)
>> + ret = mem_cgroup_sockets_init(cont, ss);
>> return ret;
>> };
>
> You does initizalication here. The reason what I think is
> 1. 'proto_list' is not available at createion of root cgroup and
> you need to delay set up until mounting.
>
> If so, please add comment or find another way.
> This seems not very clean to me.
Yes, we do can run into some ordering issues. A part of the
initialization can be done earlier. But I preferred to move it all later
instead of creating two functions for it. But I can change that if you
want, no big deal.
>
>
>
>
>> +static DEFINE_RWLOCK(proto_list_lock);
>> +static LIST_HEAD(proto_list);
>> +
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss)
>> +{
>> + struct proto *proto;
>> + int ret = 0;
>> +
>> + read_lock(&proto_list_lock);
>> + list_for_each_entry(proto,&proto_list, node) {
>> + if (proto->init_cgroup)
>> + ret = proto->init_cgroup(cgrp, ss);
>> + if (ret)
>> + goto out;
>> + }
>
> seems indent is bad or {} is missing.
>
Thanks. I'll rewrite it, since I did miss {} around the first if. But no
test could possibly catch it, since what I wanted to write, and what I
wrote by mistake end up being equivalent.
>> +EXPORT_SYMBOL(memcg_tcp_enter_memory_pressure);
>> +
>> +int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
>> +{
>> + /*
>> + * The root cgroup does not use res_counters, but rather,
>> + * rely on the data already collected by the network
>> + * subsystem
>> + */
>> + struct res_counter *res_parent = NULL;
>> + struct cg_proto *cg_proto;
>> + struct tcp_memcontrol *tcp;
>> + struct mem_cgroup *memcg = mem_cgroup_from_cont(cgrp);
>> + struct mem_cgroup *parent = parent_mem_cgroup(memcg);
>> +
>> + cg_proto = tcp_prot.proto_cgroup(memcg);
>> + if (!cg_proto)
>> + return 0;
>> +
>> + tcp = tcp_from_cgproto(cg_proto);
>> + cg_proto->parent = tcp_prot.proto_cgroup(parent);
>> +
>> + tcp->tcp_prot_mem[0] = sysctl_tcp_mem[0];
>> + tcp->tcp_prot_mem[1] = sysctl_tcp_mem[1];
>> + tcp->tcp_prot_mem[2] = sysctl_tcp_mem[2];
>> + tcp->tcp_memory_pressure = 0;
>
> Question:
>
> Is this value will be updated when an admin chages sysctl ?
yes.
> I guess, this value is set at system init script or some which may
> happen later than mounting cgroup.
> I don't like to write a guideline 'please set sysctl val before
> mounting cgroup'
Agreed.
This code is in patch 6 (together with the limiting):
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
+ rcu_read_lock();
+ memcg = mem_cgroup_from_task(current);
+
+ tcp_prot_mem(memcg, vec[0], 0);
+ tcp_prot_mem(memcg, vec[1], 1);
+ tcp_prot_mem(memcg, vec[2], 2);
+ rcu_read_unlock();
+#endif
tcp_prot_mem is just a wrapper around the assignment so we can access
memcg's inner fields.
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-12-02 17:57 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-29 23:56 [PATCH v7 00/10] Request for Inclusion: per-cgroup tcp memory pressure Glauber Costa
2011-11-29 23:56 ` Glauber Costa
2011-11-29 23:56 ` [PATCH v7 01/10] Basic kernel memory functionality for the Memory Controller Glauber Costa
2011-11-29 23:56 ` Glauber Costa
[not found] ` <1322611021-1730-2-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30 0:48 ` KAMEZAWA Hiroyuki
2011-11-30 0:48 ` KAMEZAWA Hiroyuki
2011-11-30 0:48 ` KAMEZAWA Hiroyuki
2011-11-29 23:56 ` [PATCH v7 02/10] foundations of per-cgroup memory pressure controlling Glauber Costa
2011-11-29 23:56 ` Glauber Costa
2011-11-30 0:43 ` KAMEZAWA Hiroyuki
2011-11-30 0:43 ` KAMEZAWA Hiroyuki
2011-12-02 17:46 ` Glauber Costa
2011-12-02 17:46 ` Glauber Costa
2011-12-02 17:46 ` Glauber Costa
2011-12-05 1:59 ` KAMEZAWA Hiroyuki
2011-12-05 1:59 ` KAMEZAWA Hiroyuki
2011-12-05 1:59 ` KAMEZAWA Hiroyuki
2011-12-05 9:06 ` Glauber Costa
2011-12-05 9:06 ` Glauber Costa
2011-12-05 9:06 ` Glauber Costa
2011-11-29 23:56 ` [PATCH v7 03/10] socket: initial cgroup code Glauber Costa
2011-11-29 23:56 ` Glauber Costa
[not found] ` <1322611021-1730-4-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30 1:07 ` KAMEZAWA Hiroyuki
2011-11-30 1:07 ` KAMEZAWA Hiroyuki
2011-11-30 1:07 ` KAMEZAWA Hiroyuki
2011-11-29 23:56 ` [PATCH v7 04/10] tcp memory pressure controls Glauber Costa
2011-11-29 23:56 ` Glauber Costa
[not found] ` <1322611021-1730-5-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30 1:49 ` KAMEZAWA Hiroyuki
2011-11-30 1:49 ` KAMEZAWA Hiroyuki
2011-11-30 1:49 ` KAMEZAWA Hiroyuki
[not found] ` <20111130104943.d9b210ee.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-12-02 17:57 ` Glauber Costa [this message]
2011-12-02 17:57 ` Glauber Costa
2011-12-02 17:57 ` Glauber Costa
2011-12-02 17:57 ` Glauber Costa
[not found] ` <4ED91188.6030503-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-05 2:01 ` KAMEZAWA Hiroyuki
2011-12-05 2:01 ` KAMEZAWA Hiroyuki
2011-12-05 2:01 ` KAMEZAWA Hiroyuki
2011-12-05 2:01 ` KAMEZAWA Hiroyuki
2011-11-29 23:56 ` [PATCH v7 05/10] per-netns ipv4 sysctl_tcp_mem Glauber Costa
2011-11-29 23:56 ` Glauber Costa
2011-11-29 23:56 ` [PATCH v7 06/10] tcp buffer limitation: per-cgroup limit Glauber Costa
2011-11-29 23:56 ` Glauber Costa
[not found] ` <1322611021-1730-7-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30 2:00 ` KAMEZAWA Hiroyuki
2011-11-30 2:00 ` KAMEZAWA Hiroyuki
2011-11-30 2:00 ` KAMEZAWA Hiroyuki
2011-11-29 23:56 ` [PATCH v7 07/10] Display current tcp memory allocation in kmem cgroup Glauber Costa
2011-11-29 23:56 ` Glauber Costa
2011-11-29 23:56 ` [PATCH v7 08/10] Display current tcp failcnt " Glauber Costa
2011-11-29 23:56 ` Glauber Costa
2011-11-30 2:01 ` KAMEZAWA Hiroyuki
2011-11-30 2:01 ` KAMEZAWA Hiroyuki
2011-11-29 23:57 ` [PATCH v7 09/10] Display maximum tcp memory allocation " Glauber Costa
2011-11-29 23:57 ` Glauber Costa
[not found] ` <1322611021-1730-10-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30 2:02 ` KAMEZAWA Hiroyuki
2011-11-30 2:02 ` KAMEZAWA Hiroyuki
2011-11-30 2:02 ` KAMEZAWA Hiroyuki
2011-11-29 23:57 ` [PATCH v7 10/10] Disable task moving when using kernel memory accounting Glauber Costa
2011-11-29 23:57 ` Glauber Costa
[not found] ` <1322611021-1730-11-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30 2:22 ` KAMEZAWA Hiroyuki
2011-11-30 2:22 ` KAMEZAWA Hiroyuki
2011-11-30 2:22 ` KAMEZAWA Hiroyuki
[not found] ` <20111130112210.1d979512.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-12-02 18:11 ` Glauber Costa
2011-12-02 18:11 ` Glauber Costa
2011-12-02 18:11 ` Glauber Costa
2011-12-02 18:11 ` Glauber Costa
[not found] ` <4ED914EC.6020500-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-05 2:18 ` KAMEZAWA Hiroyuki
2011-12-05 2:18 ` KAMEZAWA Hiroyuki
2011-12-05 2:18 ` KAMEZAWA Hiroyuki
2011-12-05 2:18 ` KAMEZAWA Hiroyuki
2011-12-05 9:18 ` Glauber Costa
2011-12-05 9:18 ` Glauber Costa
2011-12-05 9:18 ` Glauber Costa
[not found] ` <4EDC8C6D.2070001-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-06 0:07 ` KAMEZAWA Hiroyuki
2011-12-06 0:07 ` KAMEZAWA Hiroyuki
2011-12-06 0:07 ` KAMEZAWA Hiroyuki
2011-12-06 0:07 ` KAMEZAWA Hiroyuki
[not found] ` <1322611021-1730-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30 2:11 ` [PATCH v7 00/10] Request for Inclusion: per-cgroup tcp memory pressure KAMEZAWA Hiroyuki
2011-11-30 2:11 ` KAMEZAWA Hiroyuki
2011-11-30 2:11 ` KAMEZAWA Hiroyuki
[not found] ` <20111130111152.6b1c7366.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-12-02 18:04 ` Glauber Costa
2011-12-02 18:04 ` Glauber Costa
2011-12-02 18:04 ` Glauber Costa
2011-12-02 18:04 ` Glauber Costa
[not found] ` <4ED91318.1030803-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-05 2:06 ` KAMEZAWA Hiroyuki
2011-12-05 2:06 ` KAMEZAWA Hiroyuki
2011-12-05 2:06 ` KAMEZAWA Hiroyuki
2011-12-05 2:06 ` KAMEZAWA Hiroyuki
2011-12-05 9:09 ` Glauber Costa
2011-12-05 9:09 ` Glauber Costa
2011-12-05 9:09 ` Glauber Costa
[not found] ` <4EDC8A5F.8040402-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-05 9:51 ` KAMEZAWA Hiroyuki
2011-12-05 9:51 ` KAMEZAWA Hiroyuki
2011-12-05 9:51 ` KAMEZAWA Hiroyuki
2011-12-05 9:51 ` KAMEZAWA Hiroyuki
2011-12-05 10:28 ` Glauber Costa
2011-12-05 10:28 ` Glauber Costa
2011-12-05 10:28 ` Glauber Costa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ED91188.6030503@parallels.com \
--to=glommer-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=avagin-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=kamezawa.hiroyu-LdfC7J4mv27QFUHtdCDX3A@public.gmane.org \
--cc=kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.