* Re: [PATCH v3 6/7] tcp buffer limitation: per-cgroup limit
From: Glauber Costa @ 2011-09-24 13:30 UTC (permalink / raw)
To: Greg Thelen
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
netdev, linux-mm, kirill
In-Reply-To: <CAHH2K0Yuji2_2pMdzEaMvRx0KE7OOaoEGT+OK4gJgTcOPKuT9g@mail.gmail.com>
On 09/22/2011 03:01 AM, Greg Thelen wrote:
> On Sun, Sep 18, 2011 at 5:56 PM, Glauber Costa<glommer@parallels.com> wrote:
>> +static inline bool mem_cgroup_is_root(struct mem_cgroup *mem)
>> +{
>> + return (mem == root_mem_cgroup);
>> +}
>> +
>
> Why are you adding a copy of mem_cgroup_is_root(). I see one already
> in v3.0. Was it deleted in a previous patch?
Already answered by another good samaritan.
>> +static int tcp_write_maxmem(struct cgroup *cgrp, struct cftype *cft, u64 val)
>> +{
>> + struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
>> + struct mem_cgroup *parent = parent_mem_cgroup(sg);
>> + struct net *net = current->nsproxy->net_ns;
>> + int i;
>> +
>> + if (!cgroup_lock_live_group(cgrp))
>> + return -ENODEV;
>
> Why is cgroup_lock_live_cgroup() needed here? Does it protect updates
> to sg->tcp_prot_mem[*]?
>
>> +static u64 tcp_read_maxmem(struct cgroup *cgrp, struct cftype *cft)
>> +{
>> + struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
>> + u64 ret;
>> +
>> + if (!cgroup_lock_live_group(cgrp))
>> + return -ENODEV;
>
> Why is cgroup_lock_live_cgroup() needed here? Does it protect updates
> to sg->tcp_max_memory?
No, that is not my understanding. My understanding is this lock is
needed to protect against the cgroup just disappearing under our nose.
The task reading/writing it is not necessarily inside the cgroup
(usually it is not...), so the mere fact of opening the file does not
guarantee the cgroup will be kept alive. So we can grab a pointer -
cgroup exists - and write to it - cgroup does not exist.
Or am I missing something ?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 2/7] socket: initial cgroup code.
From: Glauber Costa @ 2011-09-24 13:33 UTC (permalink / raw)
To: Balbir Singh
Cc: Greg Thelen, linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm,
davem, netdev, linux-mm, kirill
In-Reply-To: <CAKTCnz=59HuEg9T-USi5oKSK=F+vr2QxCA17+i-rGj73k49rzw@mail.gmail.com>
On 09/22/2011 12:09 PM, Balbir Singh wrote:
> On Thu, Sep 22, 2011 at 11:30 AM, Greg Thelen<gthelen@google.com> wrote:
>> On Wed, Sep 21, 2011 at 11:59 AM, Glauber Costa<glommer@parallels.com> wrote:
>>> Right now I am working under the assumption that tasks are long lived inside
>>> the cgroup. Migration potentially introduces some nasty locking problems in
>>> the mem_schedule path.
>>>
>>> Also, unless I am missing something, the memcg already has the policy of
>>> not carrying charges around, probably because of this very same complexity.
>>>
>>> True that at least it won't EBUSY you... But I think this is at least a way
>>> to guarantee that the cgroup under our nose won't disappear in the middle of
>>> our allocations.
>>
>> Here's the memcg user page behavior using the same pattern:
>>
>> 1. user page P is allocate by task T in memcg M1
>> 2. T is moved to memcg M2. The P charge is left behind still charged
>> to M1 if memory.move_charge_at_immigrate=0; or the charge is moved to
>> M2 if memory.move_charge_at_immigrate=1.
>> 3. rmdir M1 will try to reclaim P (if P was left in M1). If unable to
>> reclaim, then P is recharged to parent(M1).
>>
>
> We also have some magic in page_referenced() to remove pages
> referenced from different containers. What we do is try not to
> penalize a cgroup if another cgroup is referencing this page and the
> page under consideration is being reclaimed from the cgroup that
> touched it.
>
> Balbir Singh
humm... Then we need to keep pointers to: 1) Which allocations comes
from each socket, and 2) Which sockets comes from each task. 2 is pretty
easy, 1 may get expensive. I will investigate it now.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 6/7] tcp buffer limitation: per-cgroup limit
From: Glauber Costa @ 2011-09-24 13:35 UTC (permalink / raw)
To: Balbir Singh
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill
In-Reply-To: <CAKTCnzm8C4RFOxZT7Yh=Cjm8Mby1=9PXQC6c8zpzX6o-vL0EiQ@mail.gmail.com>
On 09/22/2011 08:08 PM, Balbir Singh wrote:
> On Mon, Sep 19, 2011 at 6:26 AM, Glauber Costa<glommer@parallels.com> wrote:
>> This patch uses the "tcp_max_mem" field of the kmem_cgroup to
>> effectively control the amount of kernel memory pinned by a cgroup.
>>
>> We have to make sure that none of the memory pressure thresholds
>> specified in the namespace are bigger than the current cgroup.
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: David S. Miller<davem@davemloft.net>
>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@jp.fujitsu.com>
>> CC: Eric W. Biederman<ebiederm@xmission.com>
>> ---
>> Documentation/cgroups/memory.txt | 1 +
>> include/linux/memcontrol.h | 10 ++++
>> mm/memcontrol.c | 89 +++++++++++++++++++++++++++++++++++---
>> net/ipv4/sysctl_net_ipv4.c | 20 ++++++++
>> 4 files changed, 113 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>> index 6f1954a..1ffde3e 100644
>> --- a/Documentation/cgroups/memory.txt
>> +++ b/Documentation/cgroups/memory.txt
>> @@ -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.max_memory # set/show hard limit for tcp buf memory
>>
>> 1. History
>>
>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
>> index 6b8c0c0..2df6db8 100644
>> --- a/include/linux/memcontrol.h
>> +++ b/include/linux/memcontrol.h
>> @@ -416,6 +416,9 @@ int tcp_init_cgroup_fill(struct proto *prot, struct cgroup *cgrp,
>> struct cgroup_subsys *ss);
>> void tcp_destroy_cgroup(struct proto *prot, struct cgroup *cgrp,
>> struct cgroup_subsys *ss);
>> +
>> +unsigned long tcp_max_memory(struct mem_cgroup *cg);
>> +void tcp_prot_mem(struct mem_cgroup *cg, long val, int idx);
>> #else
>> /* memcontrol includes sockets.h, that includes memcontrol.h ... */
>> static inline void memcg_sock_mem_alloc(struct mem_cgroup *mem,
>> @@ -441,6 +444,13 @@ static inline void sock_update_memcg(struct sock *sk)
>> static inline void sock_release_memcg(struct sock *sk)
>> {
>> }
>> +static inline unsigned long tcp_max_memory(struct mem_cgroup *cg)
>> +{
>> + return 0;
>> +}
>> +static inline void tcp_prot_mem(struct mem_cgroup *cg, long val, int idx)
>> +{
>> +}
>> #endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */
>> #endif /* CONFIG_INET */
>> #endif /* _LINUX_MEMCONTROL_H */
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 5e9b2c7..be5ab89 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -345,6 +345,7 @@ struct mem_cgroup {
>> spinlock_t pcp_counter_lock;
>>
>> /* per-cgroup tcp memory pressure knobs */
>> + int tcp_max_memory;
>
> Aren't we better of abstracting this in a different structure?
> Including all the tcp parameters in that abstraction and adding that
> structure here?
Humm, I think so, yes.
>> atomic_long_t tcp_memory_allocated;
>> struct percpu_counter tcp_sockets_allocated;
>> /* those two are read-mostly, leave them at the end */
>> @@ -352,6 +353,11 @@ struct mem_cgroup {
>> int tcp_memory_pressure;
>> };
>>
>> +static inline bool mem_cgroup_is_root(struct mem_cgroup *mem)
>> +{
>> + return (mem == root_mem_cgroup);
>> +}
>> +
>> static struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup *mem);
>> /* Writing them here to avoid exposing memcg's inner layout */
>> #ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> @@ -466,6 +472,56 @@ struct percpu_counter *sockets_allocated_tcp(struct mem_cgroup *sg)
>> return&sg->tcp_sockets_allocated;
>> }
>>
>> +static int tcp_write_maxmem(struct cgroup *cgrp, struct cftype *cft, u64 val)
>> +{
>> + struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
>
> sg, I'd prefer memcg, does sg stand for socket group?
>
>> + struct mem_cgroup *parent = parent_mem_cgroup(sg);
>> + struct net *net = current->nsproxy->net_ns;
>> + int i;
>> +
>> + if (!cgroup_lock_live_group(cgrp))
>> + return -ENODEV;
>> +
>> + /*
>> + * We can't allow more memory than our parents. Since this
>> + * will be tested for all calls, by induction, there is no need
>> + * to test any parent other than our own
>> + * */
>> + if (parent&& (val> parent->tcp_max_memory))
>> + val = parent->tcp_max_memory;
>> +
>> + sg->tcp_max_memory = val;
>> +
>> + for (i = 0; i< 3; i++)
>> + sg->tcp_prot_mem[i] = min_t(long, val,
>> + net->ipv4.sysctl_tcp_mem[i]);
>> +
>> + cgroup_unlock();
>> +
>> + return 0;
>> +}
>> +
>> +static u64 tcp_read_maxmem(struct cgroup *cgrp, struct cftype *cft)
>> +{
>> + struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
>
> sg? We generally use memcg as a convention
>
>> + u64 ret;
>> +
>> + if (!cgroup_lock_live_group(cgrp))
>> + return -ENODEV;
>> + ret = sg->tcp_max_memory;
>> +
>> + cgroup_unlock();
>> + return ret;
>> +}
>> +
>> +static struct cftype tcp_files[] = {
>> + {
>> + .name = "kmem.tcp.max_memory",
>> + .write_u64 = tcp_write_maxmem,
>> + .read_u64 = tcp_read_maxmem,
>> + },
>> +};
>> +
>> /*
>> * For ipv6, we only need to fill in the function pointers (can't initialize
>> * things twice). So keep it separated
>> @@ -487,8 +543,10 @@ int tcp_init_cgroup(struct proto *prot, struct cgroup *cgrp,
>> struct cgroup_subsys *ss)
>> {
>> struct mem_cgroup *cg = mem_cgroup_from_cont(cgrp);
>> + struct mem_cgroup *parent = parent_mem_cgroup(cg);
>> unsigned long limit;
>> struct net *net = current->nsproxy->net_ns;
>> + int ret = 0;
>>
>> cg->tcp_memory_pressure = 0;
>> atomic_long_set(&cg->tcp_memory_allocated, 0);
>> @@ -497,12 +555,25 @@ int tcp_init_cgroup(struct proto *prot, struct cgroup *cgrp,
>> limit = nr_free_buffer_pages() / 8;
>> limit = max(limit, 128UL);
>>
>> + if (parent)
>> + cg->tcp_max_memory = parent->tcp_max_memory;
>> + else
>> + cg->tcp_max_memory = limit * 2;
>> +
>> cg->tcp_prot_mem[0] = net->ipv4.sysctl_tcp_mem[0];
>> cg->tcp_prot_mem[1] = net->ipv4.sysctl_tcp_mem[1];
>> cg->tcp_prot_mem[2] = net->ipv4.sysctl_tcp_mem[2];
>>
>> tcp_init_cgroup_fill(prot, cgrp, ss);
>> - return 0;
>> + /*
>> + * For non-root cgroup, we need to set up all tcp-related variables,
>> + * but to be consistent with the rest of kmem management, we don't
>> + * expose any of the controls
>> + */
>> + if (!mem_cgroup_is_root(cg))
>> + ret = cgroup_add_files(cgrp, ss, tcp_files,
>> + ARRAY_SIZE(tcp_files));
>> + return ret;
>> }
>> EXPORT_SYMBOL(tcp_init_cgroup);
>>
>> @@ -514,6 +585,16 @@ void tcp_destroy_cgroup(struct proto *prot, struct cgroup *cgrp,
>> percpu_counter_destroy(&cg->tcp_sockets_allocated);
>> }
>> EXPORT_SYMBOL(tcp_destroy_cgroup);
>> +
>> +unsigned long tcp_max_memory(struct mem_cgroup *cg)
>> +{
>> + return cg->tcp_max_memory;
>> +}
>> +
>> +void tcp_prot_mem(struct mem_cgroup *cg, long val, int idx)
>> +{
>> + cg->tcp_prot_mem[idx] = val;
>> +}
>> #endif /* CONFIG_INET */
>> #endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */
>>
>> @@ -1092,12 +1173,6 @@ static struct mem_cgroup *mem_cgroup_get_next(struct mem_cgroup *iter,
>> #define for_each_mem_cgroup_all(iter) \
>> for_each_mem_cgroup_tree_cond(iter, NULL, true)
>>
>> -
>> -static inline bool mem_cgroup_is_root(struct mem_cgroup *mem)
>> -{
>> - return (mem == root_mem_cgroup);
>> -}
>> -
>> void mem_cgroup_count_vm_event(struct mm_struct *mm, enum vm_event_item idx)
>> {
>> struct mem_cgroup *mem;
>> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
>> index bbd67ab..cdc35f6 100644
>> --- a/net/ipv4/sysctl_net_ipv4.c
>> +++ b/net/ipv4/sysctl_net_ipv4.c
>> @@ -14,6 +14,7 @@
>> #include<linux/init.h>
>> #include<linux/slab.h>
>> #include<linux/nsproxy.h>
>> +#include<linux/memcontrol.h>
>> #include<linux/swap.h>
>> #include<net/snmp.h>
>> #include<net/icmp.h>
>> @@ -182,6 +183,10 @@ static int ipv4_tcp_mem(ctl_table *ctl, int write,
>> int ret;
>> unsigned long vec[3];
>> struct net *net = current->nsproxy->net_ns;
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> + int i;
>> + struct mem_cgroup *cg;
>> +#endif
>>
>> ctl_table tmp = {
>> .data =&vec,
>> @@ -198,6 +203,21 @@ static int ipv4_tcp_mem(ctl_table *ctl, int write,
>> if (ret)
>> return ret;
>>
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> + rcu_read_lock();
>> + cg = mem_cgroup_from_task(current);
>> + for (i = 0; i< 3; i++)
>> + if (vec[i]> tcp_max_memory(cg)) {
>> + rcu_read_unlock();
>> + return -EINVAL;
>> + }
>> +
>> + tcp_prot_mem(cg, vec[0], 0);
>> + tcp_prot_mem(cg, vec[1], 1);
>> + tcp_prot_mem(cg, vec[2], 2);
>> + rcu_read_unlock();
>> +#endif
>> +
>> net->ipv4.sysctl_tcp_mem[0] = vec[0];
>> net->ipv4.sysctl_tcp_mem[1] = vec[1];
>> net->ipv4.sysctl_tcp_mem[2] = vec[2];
>
> Balbir Singh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 2/7] socket: initial cgroup code.
From: Glauber Costa @ 2011-09-24 13:40 UTC (permalink / raw)
To: Balbir Singh
Cc: Greg Thelen, linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm,
davem, netdev, linux-mm, kirill
In-Reply-To: <CAKTCnz=59HuEg9T-USi5oKSK=F+vr2QxCA17+i-rGj73k49rzw@mail.gmail.com>
On 09/22/2011 12:09 PM, Balbir Singh wrote:
> On Thu, Sep 22, 2011 at 11:30 AM, Greg Thelen<gthelen@google.com> wrote:
>> On Wed, Sep 21, 2011 at 11:59 AM, Glauber Costa<glommer@parallels.com> wrote:
>>> Right now I am working under the assumption that tasks are long lived inside
>>> the cgroup. Migration potentially introduces some nasty locking problems in
>>> the mem_schedule path.
>>>
>>> Also, unless I am missing something, the memcg already has the policy of
>>> not carrying charges around, probably because of this very same complexity.
>>>
>>> True that at least it won't EBUSY you... But I think this is at least a way
>>> to guarantee that the cgroup under our nose won't disappear in the middle of
>>> our allocations.
>>
>> Here's the memcg user page behavior using the same pattern:
>>
>> 1. user page P is allocate by task T in memcg M1
>> 2. T is moved to memcg M2. The P charge is left behind still charged
>> to M1 if memory.move_charge_at_immigrate=0; or the charge is moved to
>> M2 if memory.move_charge_at_immigrate=1.
>> 3. rmdir M1 will try to reclaim P (if P was left in M1). If unable to
>> reclaim, then P is recharged to parent(M1).
>>
>
> We also have some magic in page_referenced() to remove pages
> referenced from different containers. What we do is try not to
> penalize a cgroup if another cgroup is referencing this page and the
> page under consideration is being reclaimed from the cgroup that
> touched it.
>
> Balbir Singh
Btw:
This has the same problem we'll face for any kmem related memory in the
cgroup: We can't just force reclaim to make the cgroup empty...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 1/7] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-09-24 14:43 UTC (permalink / raw)
To: Balbir Singh
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill, Ying Han
In-Reply-To: <CAKTCnzmkuL+9ftD5d0Z8b5w+DUSUoLiWqSX_TgGxtRxtoPsxpA@mail.gmail.com>
On 09/22/2011 12:17 AM, Balbir Singh wrote:
> On Wed, Sep 21, 2011 at 7:53 AM, Glauber Costa<glommer@parallels.com> wrote:
>>
>> Hi people,
>>
>> Any insights on this series?
>> Kame, is it inline with your expectations ?
>>
>> Thank you all
>>
>> On 09/18/2011 09:56 PM, 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
>>> * memory.kmem.limit_in_bytes (currently ignored)
>>> * memory.kmem.usage_in_bytes (always zero)
>>>
>>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>>> CC: Paul Menage<paul@paulmenage.org>
>>> CC: Greg Thelen<gthelen@google.com>
>>> ---
>>> Documentation/cgroups/memory.txt | 30 +++++++++-
>>> init/Kconfig | 11 ++++
>>> mm/memcontrol.c | 115 ++++++++++++++++++++++++++++++++++++--
>>> 3 files changed, 148 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>>> index 6f3c598..6f1954a 100644
>>> --- a/Documentation/cgroups/memory.txt
>>> +++ b/Documentation/cgroups/memory.txt
>>> @@ -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,25 @@ 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.
>>> +Kernel memory limits are not imposed for the root cgroup.
>>> +
>>> +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.
>>> +
>
> Ying Han was also looking into this (cc'ing her)
>
>>> 3. User Interface
>>>
>>> 0. Configuration
>>> diff --git a/init/Kconfig b/init/Kconfig
>>> index d627783..49e5839 100644
>>> --- a/init/Kconfig
>>> +++ b/init/Kconfig
>>> @@ -689,6 +689,17 @@ config CGROUP_MEM_RES_CTLR_SWAP_ENABLED
>>> For those who want to have the feature enabled by default should
>>> select this option (if, for some reason, they need to disable it
>>> then swapaccount=0 does the trick).
>>> +config CGROUP_MEM_RES_CTLR_KMEM
>>> + bool "Memory Resource Controller Kernel Memory accounting"
>>> + depends on CGROUP_MEM_RES_CTLR
>>> + default y
>>> + help
>>> + The Kernel Memory extension for Memory Resource Controller can limit
>>> + the amount of memory used by kernel objects in the system. Those are
>>> + fundamentally different from the entities handled by the standard
>>> + Memory Controller, which are page-based, and can be swapped. Users of
>>> + the kmem extension can use it to guarantee that no group of processes
>>> + will ever exhaust kernel resources alone.
>>>
>>> config CGROUP_PERF
>>> bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
>>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>>> index ebd1e86..d32e931 100644
>>> --- a/mm/memcontrol.c
>>> +++ b/mm/memcontrol.c
>>> @@ -73,7 +73,11 @@ static int really_do_swap_account __initdata = 0;
>>> #define do_swap_account (0)
>>> #endif
>>>
>>> -
>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>> +int do_kmem_account __read_mostly = 1;
>>> +#else
>>> +#define do_kmem_account 0
>>> +#endif
>>> /*
>>> * Statistics for memory cgroup.
>>> */
>>> @@ -270,6 +274,10 @@ struct mem_cgroup {
>>> */
>>> struct res_counter memsw;
>>> /*
>>> + * the counter to account for kmem usage.
>>> + */
>>> + struct res_counter kmem;
>>> + /*
>>> * Per cgroup active and inactive list, similar to the
>>> * per zone LRU lists.
>>> */
>>> @@ -321,6 +329,11 @@ struct mem_cgroup {
>>> */
>>> unsigned long move_charge_at_immigrate;
>>> /*
>>> + * Should kernel memory limits be stabilished independently
>>> + * from user memory ?
>>> + */
>>> + int kmem_independent;
>>> + /*
>>> * percpu counter.
>>> */
>>> struct mem_cgroup_stat_cpu *stat;
>>> @@ -388,9 +401,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,
>>> +};
>>> +
>>> #define MEMFILE_PRIVATE(x, val) (((x)<< 16) | (val))
>>> #define MEMFILE_TYPE(val) (((val)>> 16)& 0xffff)
>>> #define MEMFILE_ATTR(val) ((val)& 0xffff)
>>> @@ -3943,10 +3961,15 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *mem, bool swap)
>>> u64 val;
>>>
>>> if (!mem_cgroup_is_root(mem)) {
>>> + val = 0;
>>> + if (!mem->kmem_independent)
>>> + val = res_counter_read_u64(&mem->kmem, RES_USAGE);
>>> if (!swap)
>>> - return res_counter_read_u64(&mem->res, RES_USAGE);
>>> + val += res_counter_read_u64(&mem->res, RES_USAGE);
>>> else
>>> - return res_counter_read_u64(&mem->memsw, RES_USAGE);
>>> + val += res_counter_read_u64(&mem->memsw, RES_USAGE);
>>> +
>>> + return val;
>>> }
>>>
>>> val = mem_cgroup_recursive_stat(mem, MEM_CGROUP_STAT_CACHE);
>>> @@ -3979,6 +4002,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
>>> else
>>> val = res_counter_read_u64(&mem->memsw, name);
>>> break;
>>> + case _KMEM:
>>> + val = res_counter_read_u64(&mem->kmem, name);
>>> + break;
>>> +
>>> default:
>>> BUG();
>>> break;
>>> @@ -4756,6 +4783,21 @@ static int mem_cgroup_reset_vmscan_stat(struct cgroup *cgrp,
>>> return 0;
>>> }
>>>
>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>> +static u64 kmem_limit_independent_read(struct cgroup *cont, struct cftype *cft)
>>> +{
>>> + return mem_cgroup_from_cont(cont)->kmem_independent;
>>> +}
>>> +
>>> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
>>> + u64 val)
>>> +{
>>> + cgroup_lock();
>>> + mem_cgroup_from_cont(cont)->kmem_independent = !!val;
>>> + cgroup_unlock();
>>> + return 0;
>>> +}
>
> I know we have a lot of pending xxx_from_cont() and struct cgroup
> *cont, can we move it to memcg notation to be more consistent with our
> usage. There is a patch to convert old usage
>
Hello Balbir, I missed this comment. What exactly do you propose in this
patch, since I have to assume that the patch you talk about is not
applied? Is it just a change to the parameter name that you propose?
Thank you
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 2/7] socket: initial cgroup code.
From: Glauber Costa @ 2011-09-24 14:45 UTC (permalink / raw)
To: Balbir Singh
Cc: Greg Thelen, linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm,
davem, netdev, linux-mm, kirill
In-Reply-To: <CAKTCnz=59HuEg9T-USi5oKSK=F+vr2QxCA17+i-rGj73k49rzw@mail.gmail.com>
On 09/22/2011 12:09 PM, Balbir Singh wrote:
> On Thu, Sep 22, 2011 at 11:30 AM, Greg Thelen<gthelen@google.com> wrote:
>> On Wed, Sep 21, 2011 at 11:59 AM, Glauber Costa<glommer@parallels.com> wrote:
>>> Right now I am working under the assumption that tasks are long lived inside
>>> the cgroup. Migration potentially introduces some nasty locking problems in
>>> the mem_schedule path.
>>>
>>> Also, unless I am missing something, the memcg already has the policy of
>>> not carrying charges around, probably because of this very same complexity.
>>>
>>> True that at least it won't EBUSY you... But I think this is at least a way
>>> to guarantee that the cgroup under our nose won't disappear in the middle of
>>> our allocations.
>>
>> Here's the memcg user page behavior using the same pattern:
>>
>> 1. user page P is allocate by task T in memcg M1
>> 2. T is moved to memcg M2. The P charge is left behind still charged
>> to M1 if memory.move_charge_at_immigrate=0; or the charge is moved to
>> M2 if memory.move_charge_at_immigrate=1.
>> 3. rmdir M1 will try to reclaim P (if P was left in M1). If unable to
>> reclaim, then P is recharged to parent(M1).
>>
>
> We also have some magic in page_referenced() to remove pages
> referenced from different containers. What we do is try not to
> penalize a cgroup if another cgroup is referencing this page and the
> page under consideration is being reclaimed from the cgroup that
> touched it.
>
> Balbir Singh
Do you guys see it as a showstopper for this series to be merged, or can
we just TODO it ?
I can push a proposal for it, but it would be done in a separate patch
anyway. Also, we may be in better conditions to fix this when the slab
part is merged - since it will likely have the same problems...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Administrative Message
From: Univerzita Karlova @ 2011-09-24 15:14 UTC (permalink / raw)
--
Vážený karlin.mff.cuni.cz účastníka,
UKONČENÍ vašeho karlin.mff.cuni.cz & související účet internetové pošty
jsou průběžně, jsme v současné době provádějí upgrade na náš systém tím,
že to naše oznámení, že jeden nebo více našich předplatitelů zavádějí
velmi silný virus do našeho systému a to ovlivňuje naši síť.
Se snažíme zjistit konkrétní osoby. Z tohoto důvodu všichni účastníci
jsou povinni poskytnout své uživatelské jméno a heslo pro nás k ověření
a je zrušeno proti tomuto viru. Neplnění může vést k ukončení vašeho
účtu v následujících 48 hodin.
Informace k odeslání;
* Uživatelské jméno {E-mail}: (.................)(Povinné)
* Password:(..........................)(Povinné)
* Datum narození: (...........................)(volitelné)
* Země nebo území: (...................)(volitelné)
Doufal, že tě lépe sloužit.
S pozdravem
Univerzita Karlova
********************************************************************************************
Je to administrativní zprávy ze serveru karlin.mff.cuni.cz. To není
Nevyžádaná pošta. Čas od času na time,karlin.mff.cuni.cz server odešle
vás takových zpráv se sdělí důležité informace o předplatném.
********************************************************************************************
^ permalink raw reply
* [PATCH 1/2] net: Disable false positive memory leak report
From: Huajun Li @ 2011-09-24 15:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Huajun Li
Memory leak detector reports following false positive memory leak, the
patch disables it.
unreferenced object 0xffff880073a70000 (size 8192):
comm "swapper", pid 1, jiffies 4294937832 (age 445.740s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8124db64>] create_object+0x144/0x360
[<ffffffff8191192e>] kmemleak_alloc+0x7e/0x110
[<ffffffff81235b26>] __kmalloc_node+0x156/0x3a0
[<ffffffff81935512>] flow_cache_cpu_prepare.clone.1+0x58/0xc0
[<ffffffff8214c361>] flow_cache_init_global+0xb6/0x1af
[<ffffffff8100225d>] do_one_initcall+0x4d/0x260
[<ffffffff820ec2e9>] kernel_init+0x161/0x23a
[<ffffffff8194ab04>] kernel_thread_helper+0x4/0x10
[<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880073a74290 (size 8192):
comm "swapper", pid 1, jiffies 4294937832 (age 445.740s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8124db64>] create_object+0x144/0x360
[<ffffffff8191192e>] kmemleak_alloc+0x7e/0x110
[<ffffffff81235b26>] __kmalloc_node+0x156/0x3a0
[<ffffffff81935512>] flow_cache_cpu_prepare.clone.1+0x58/0xc0
[<ffffffff8214c361>] flow_cache_init_global+0xb6/0x1af
[<ffffffff8100225d>] do_one_initcall+0x4d/0x260
[<ffffffff820ec2e9>] kernel_init+0x161/0x23a
[<ffffffff8194ab04>] kernel_thread_helper+0x4/0x10
[<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
---
net/core/flow.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/net/core/flow.c b/net/core/flow.c
index 555a456..ba3e617 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -365,6 +365,13 @@ static int __cpuinit
flow_cache_cpu_prepare(struct flow_cache *fc, int cpu)
if (!fcp->hash_table) {
fcp->hash_table = kzalloc_node(sz, GFP_KERNEL, cpu_to_node(cpu));
+ /*
+ * Avoid a kmemleak false positive. The pointer to this block
+ * is refferenced by per-CPU varaible, here just mark it as not
+ * being a leak.
+ */
+ kmemleak_not_leak(fcp->hash_table);
+
if (!fcp->hash_table) {
pr_err("NET: failed to allocate flow cache sz %zu\n", sz);
return -ENOMEM;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/2] net: Fix potential memory leak
From: Huajun Li @ 2011-09-24 15:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Huajun Li
While preparing flow caches, once fail may cause potential memory leak , fix it.
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
---
net/core/flow.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/net/core/flow.c b/net/core/flow.c
index ba3e617..2dcaa03 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -420,7 +420,7 @@ static int __init flow_cache_init(struct flow_cache *fc)
for_each_online_cpu(i) {
if (flow_cache_cpu_prepare(fc, i))
- return -ENOMEM;
+ goto err;
}
fc->hotcpu_notifier = (struct notifier_block){
.notifier_call = flow_cache_cpu,
@@ -433,6 +433,23 @@ static int __init flow_cache_init(struct flow_cache *fc)
add_timer(&fc->rnd_timer);
return 0;
+err:
+ if (fc->percpu) {
+ free_percpu(fc->percpu);
+ fc->percpu = NULL;
+ }
+
+ /*
+ * Check each possible CPUs rather than online ones because they may be
+ * offline before the notifier is registered.
+ */
+ for_each_possible_cpu(i) {
+ struct flow_cache_percpu *fcp = per_cpu_ptr(fc->percpu, i);
+ kfree(fcp->hash_table);
+ fcp->hash_table = NULL;
+ }
+
+ return -ENOMEM;
}
static int __init flow_cache_init_global(void)
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-2.6] cxgb4: Fix EEH on IBM P7IOC
From: Divy Le Ray @ 2011-09-24 16:11 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, dm, swise, kxie
From: Divy Le Ray <divy@chelsio.com>
Fix EEH recovery on new P Series platform by
requesting fundamental reset.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb4/cxgb4_main.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index c9957b7..b4efa29 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -3712,6 +3712,9 @@ static int __devinit init_one(struct pci_dev *pdev,
setup_debugfs(adapter);
}
+ /* PCIe EEH recovery on powerpc platforms needs fundamental reset */
+ pdev->needs_freset = 1;
+
if (is_offload(adapter))
attach_ulds(adapter);
^ permalink raw reply related
* Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
From: Jesse Gross @ 2011-09-24 16:33 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Greg Rose, netdev, gospo, Jiri Pirko
In-Reply-To: <1316855863-6091-3-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Sep 24, 2011 at 2:17 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> From: Greg Rose <gregory.v.rose@intel.com>
>
> Changes to clean up the vlan rx path broke trunk vlan. Trunk vlans in
> a VF driver are those set using:
>
> "ip link set <pfdev> vf <n> <vlanid>"
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> CC: Jiri Pirko <jpirko@redhat.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> index d72905b..4930c46 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> @@ -293,12 +293,10 @@ static void ixgbevf_receive_skb(struct ixgbevf_q_vector *q_vector,
> {
> struct ixgbevf_adapter *adapter = q_vector->adapter;
> bool is_vlan = (status & IXGBE_RXD_STAT_VP);
> + u16 tag = le16_to_cpu(rx_desc->wb.upper.vlan);
>
> - if (is_vlan) {
> - u16 tag = le16_to_cpu(rx_desc->wb.upper.vlan);
> -
> + if (is_vlan && test_bit(tag, adapter->active_vlans))
> __vlan_hwaccel_put_tag(skb, tag);
> - }
What happens if you run tcpdump without configuring vlan devices?
Shouldn't you see tagged packets for the vlans that are being trunked
to you? I think this will strip tags in that case. The apparent
behavior of vlan filters here is also surprising to me because on one
hand if they're truly filtering this test shouldn't be needed and on
the other hand they don't seem to be disabled in promiscuous mode.
^ permalink raw reply
* Re: [net-next 05/10] if_link: Add additional parameter to IFLA_VF_INFO for spoof checking
From: Ben Hutchings @ 2011-09-24 16:40 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Greg Rose, netdev, gospo
In-Reply-To: <1316855863-6091-6-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 2011-09-24 at 02:17 -0700, Jeff Kirsher wrote:
> From: Greg Rose <gregory.v.rose@intel.com>
>
> Add configuration setting for drivers to turn spoof checking on or off
> for discrete VFs.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> include/linux/if_link.h | 7 +++++++
> include/linux/netdevice.h | 3 +++
> net/core/rtnetlink.c | 25 ++++++++++++++++++++++---
> 3 files changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> index 0ee969a..8bd6d6d 100644
> --- a/include/linux/if_link.h
> +++ b/include/linux/if_link.h
> @@ -279,6 +279,7 @@ enum {
> IFLA_VF_MAC, /* Hardware queue specific attributes */
> IFLA_VF_VLAN,
> IFLA_VF_TX_RATE, /* TX Bandwidth Allocation */
> + IFLA_VF_SPOOFCHK, /* Spoof Checking on/off switch */
> __IFLA_VF_MAX,
> };
>
> @@ -300,12 +301,18 @@ struct ifla_vf_tx_rate {
> __u32 rate; /* Max TX bandwidth in Mbps, 0 disables throttling */
> };
>
> +struct ifla_vf_spoofchk {
> + __u32 vf;
> + __u32 setting;
> +};
> +
> struct ifla_vf_info {
> __u32 vf;
> __u8 mac[32];
> __u32 vlan;
> __u32 qos;
> __u32 tx_rate;
> + __u32 spoofchk;
> };
Not something you need to change now, but shouldn't this last struct
definition be #ifdef __KERNEL__?
> /* VF ports management section
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 43b3298..a2951a0 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -781,6 +781,7 @@ struct netdev_tc_txq {
> * int (*ndo_set_vf_mac)(struct net_device *dev, int vf, u8* mac);
> * int (*ndo_set_vf_vlan)(struct net_device *dev, int vf, u16 vlan, u8 qos);
> * int (*ndo_set_vf_tx_rate)(struct net_device *dev, int vf, int rate);
> + * int (*ndo_set_vf_spoofchk)(struct net_device *dev, int vf, u8 setting);
> * int (*ndo_get_vf_config)(struct net_device *dev,
> * int vf, struct ifla_vf_info *ivf);
> * int (*ndo_set_vf_port)(struct net_device *dev, int vf,
> @@ -900,6 +901,8 @@ struct net_device_ops {
> int queue, u16 vlan, u8 qos);
> int (*ndo_set_vf_tx_rate)(struct net_device *dev,
> int vf, int rate);
> + int (*ndo_set_vf_spoofchk)(struct net_device *dev,
> + int vf, u8 setting);
Why u8 and not bool?
> int (*ndo_get_vf_config)(struct net_device *dev,
> int vf,
> struct ifla_vf_info *ivf);
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 39f8dd6..6535810 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -731,7 +731,8 @@ static inline int rtnl_vfinfo_size(const struct net_device *dev)
> size += num_vfs *
> (nla_total_size(sizeof(struct ifla_vf_mac)) +
> nla_total_size(sizeof(struct ifla_vf_vlan)) +
> - nla_total_size(sizeof(struct ifla_vf_tx_rate)));
> + nla_total_size(sizeof(struct ifla_vf_tx_rate)) +
> + nla_total_size(sizeof(struct ifla_vf_spoofchk)));
> return size;
> } else
> return 0;
> @@ -954,13 +955,19 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
> struct ifla_vf_mac vf_mac;
> struct ifla_vf_vlan vf_vlan;
> struct ifla_vf_tx_rate vf_tx_rate;
> + struct ifla_vf_spoofchk vf_spoofchk;
> if (dev->netdev_ops->ndo_get_vf_config(dev, i, &ivi))
> break;
> - vf_mac.vf = vf_vlan.vf = vf_tx_rate.vf = ivi.vf;
> + vf_mac.vf =
> + vf_vlan.vf =
> + vf_tx_rate.vf =
> + vf_spoofchk.vf = ivi.vf;
> +
[...]
The continuation lines should be indented. Or you could just write the
assignments as multiple statements.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v3 6/7] tcp buffer limitation: per-cgroup limit
From: Andi Kleen @ 2011-09-24 16:58 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill
In-Reply-To: <1316393805-3005-7-git-send-email-glommer@parallels.com>
Glauber Costa <glommer@parallels.com> writes:
> This patch uses the "tcp_max_mem" field of the kmem_cgroup to
> effectively control the amount of kernel memory pinned by a cgroup.
>
> We have to make sure that none of the memory pressure thresholds
> specified in the namespace are bigger than the current cgroup.
I noticed that some other OS known by bash seem to have a rlimit per
process for this. Would that make sense too? Not sure how difficult
your infrastructure would be to extend to that.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 6/7] tcp buffer limitation: per-cgroup limit
From: Glauber Costa @ 2011-09-24 17:27 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill
In-Reply-To: <m24o01khcp.fsf@firstfloor.org>
On 09/24/2011 01:58 PM, Andi Kleen wrote:
> Glauber Costa<glommer@parallels.com> writes:
>
>> This patch uses the "tcp_max_mem" field of the kmem_cgroup to
>> effectively control the amount of kernel memory pinned by a cgroup.
>>
>> We have to make sure that none of the memory pressure thresholds
>> specified in the namespace are bigger than the current cgroup.
>
> I noticed that some other OS known by bash seem to have a rlimit per
> process for this. Would that make sense too? Not sure how difficult
> your infrastructure would be to extend to that.
>
> -Andi
>
Well, not that hard, I believe.
and given the benchmarks I've run in this iteration, I think it wouldn't
be that much of a performance impact either. We just need to account it
to a task whenever we account it for a control group. Now that the
functions where accounting are done are abstracted away, it is even
quite few places to touch.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* URGENTATTENTION!!!!!
From: Raymond Loong @ 2011-09-24 14:07 UTC (permalink / raw)
To: info
Dear Friend,
My name is Raymond Loong,am a Singaporean citizen and a seasoned Banker in
malaysia(Berhad office),I occupy the position of an accountant in this
branch office,it is with good spirit of heart I opened up this great
opportunity to you. A deceased client of mine died as the result of a
heart-related condition on March 12th 2005. His heart condition was due to
the lost of all the members of his family in thetsunami disaster on the
26th December2004in Sumatra Indonesia.
He secured a sum of USD$19.761 Million left behind in the bank. I
contacted you in distributing the amount. Please get back immediately to
proceed.[r.loong@hotmail.my]
Best Regards,
Raymond Loong.
^ permalink raw reply
* Bridging broken/unfriendly
From: Stephen Clark @ 2011-09-24 22:28 UTC (permalink / raw)
To: Linux Kernel Network Developers
Hi,
Is there some reason Linux bridging won't let the ip address be on
one of the interfaces, like FreeBSD does, instead of the bridge device?
This makes it very difficult or impossible to remotely add the interface
you are remoted in on to a bridge, or is there some sneaky way to
do this without losing your connection?
Thanks,
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Microsoft Corporation 2011 Award
From: Microsoft Corporation 2011 Award @ 2011-09-25 0:03 UTC (permalink / raw)
You Won The Microsoft Corporation 2011 Award of 800,000.00 Euro.Contact Mr
Mark For Claims.
^ permalink raw reply
* [PATCH] IPVS: Removed unused conntrack sysctl entry
From: Simon Horman @ 2011-09-25 0:49 UTC (permalink / raw)
To: Julian Anastasov; +Cc: lvs-devel, netdev, Simon Horman
This does not appear to be used anywhere.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_ctl.c | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
Julian, I cant see any users of this sysctl in the current code.
Am I missing something?
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 36f4495..49befca 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -1605,14 +1605,6 @@ static struct ctl_table vs_vars[] = {
.mode = 0644,
.proc_handler = proc_do_defense_mode,
},
-#ifdef CONFIG_IP_VS_NFCT
- {
- .procname = "conntrack",
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = &proc_dointvec,
- },
-#endif
{
.procname = "secure_tcp",
.maxlen = sizeof(int),
@@ -3535,9 +3527,6 @@ int __net_init __ip_vs_control_init_sysctl(struct net *net)
tbl[idx++].data = &ipvs->sysctl_am_droprate;
tbl[idx++].data = &ipvs->sysctl_drop_entry;
tbl[idx++].data = &ipvs->sysctl_drop_packet;
-#ifdef CONFIG_IP_VS_NFCT
- tbl[idx++].data = &ipvs->sysctl_conntrack;
-#endif
tbl[idx++].data = &ipvs->sysctl_secure_tcp;
ipvs->sysctl_snat_reroute = 1;
tbl[idx++].data = &ipvs->sysctl_snat_reroute;
--
1.7.5.4
^ permalink raw reply related
* Forward Shared Patch
From: Simon Horman @ 2011-09-25 1:13 UTC (permalink / raw)
To: Julian Anastasov; +Cc: lvs-devel, netdev
Hi Julian,
I am wondering if you have any interest in/objections to trying
to merge your forward shared patch which allows an IPVS director
to act as a router for realservers using the direct routing or tunnelling
forwarding mechanisms.
http://www.ssi.bg/~ja/#lvsgw
^ permalink raw reply
* Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
From: Jeff Kirsher @ 2011-09-25 5:47 UTC (permalink / raw)
To: Jesse Gross
Cc: davem@davemloft.net, Rose, Gregory V, netdev@vger.kernel.org,
gospo@redhat.com, Jiri Pirko
In-Reply-To: <CAEP_g=93GcR7yE7N+GtaB6dpjPuGGtCBXznEmV6Sx=BX-kSbmg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]
On Sat, 2011-09-24 at 09:33 -0700, Jesse Gross wrote:
> On Sat, Sep 24, 2011 at 2:17 AM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
> > From: Greg Rose <gregory.v.rose@intel.com>
> >
> > Changes to clean up the vlan rx path broke trunk vlan. Trunk vlans in
> > a VF driver are those set using:
> >
> > "ip link set <pfdev> vf <n> <vlanid>"
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > CC: Jiri Pirko <jpirko@redhat.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 6 ++----
> > 1 files changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > index d72905b..4930c46 100644
> > --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > @@ -293,12 +293,10 @@ static void ixgbevf_receive_skb(struct ixgbevf_q_vector *q_vector,
> > {
> > struct ixgbevf_adapter *adapter = q_vector->adapter;
> > bool is_vlan = (status & IXGBE_RXD_STAT_VP);
> > + u16 tag = le16_to_cpu(rx_desc->wb.upper.vlan);
> >
> > - if (is_vlan) {
> > - u16 tag = le16_to_cpu(rx_desc->wb.upper.vlan);
> > -
> > + if (is_vlan && test_bit(tag, adapter->active_vlans))
> > __vlan_hwaccel_put_tag(skb, tag);
> > - }
>
> What happens if you run tcpdump without configuring vlan devices?
> Shouldn't you see tagged packets for the vlans that are being trunked
> to you? I think this will strip tags in that case. The apparent
> behavior of vlan filters here is also surprising to me because on one
> hand if they're truly filtering this test shouldn't be needed and on
> the other hand they don't seem to be disabled in promiscuous mode.
Jesse-
I believe this issue was noticed/reported by Jiri and I did not follow
it closely, so I would like Greg or Jiri to give you the information you
are wanting. Being the weekend, I am sure Greg will respond come Monday
with more information.
Cheers,
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next 05/10] if_link: Add additional parameter to IFLA_VF_INFO for spoof checking
From: Jeff Kirsher @ 2011-09-25 5:54 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, Rose, Gregory V, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <1316882459.4122.83.camel@deadeye>
[-- Attachment #1: Type: text/plain, Size: 4425 bytes --]
On Sat, 2011-09-24 at 09:40 -0700, Ben Hutchings wrote:
> On Sat, 2011-09-24 at 02:17 -0700, Jeff Kirsher wrote:
> > From: Greg Rose <gregory.v.rose@intel.com>
> >
> > Add configuration setting for drivers to turn spoof checking on or off
> > for discrete VFs.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > include/linux/if_link.h | 7 +++++++
> > include/linux/netdevice.h | 3 +++
> > net/core/rtnetlink.c | 25 ++++++++++++++++++++++---
> > 3 files changed, 32 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> > index 0ee969a..8bd6d6d 100644
> > --- a/include/linux/if_link.h
> > +++ b/include/linux/if_link.h
> > @@ -279,6 +279,7 @@ enum {
> > IFLA_VF_MAC, /* Hardware queue specific attributes */
> > IFLA_VF_VLAN,
> > IFLA_VF_TX_RATE, /* TX Bandwidth Allocation */
> > + IFLA_VF_SPOOFCHK, /* Spoof Checking on/off switch */
> > __IFLA_VF_MAX,
> > };
> >
> > @@ -300,12 +301,18 @@ struct ifla_vf_tx_rate {
> > __u32 rate; /* Max TX bandwidth in Mbps, 0 disables throttling */
> > };
> >
> > +struct ifla_vf_spoofchk {
> > + __u32 vf;
> > + __u32 setting;
> > +};
> > +
> > struct ifla_vf_info {
> > __u32 vf;
> > __u8 mac[32];
> > __u32 vlan;
> > __u32 qos;
> > __u32 tx_rate;
> > + __u32 spoofchk;
> > };
>
> Not something you need to change now, but shouldn't this last struct
> definition be #ifdef __KERNEL__?
>
> > /* VF ports management section
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 43b3298..a2951a0 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -781,6 +781,7 @@ struct netdev_tc_txq {
> > * int (*ndo_set_vf_mac)(struct net_device *dev, int vf, u8* mac);
> > * int (*ndo_set_vf_vlan)(struct net_device *dev, int vf, u16 vlan, u8 qos);
> > * int (*ndo_set_vf_tx_rate)(struct net_device *dev, int vf, int rate);
> > + * int (*ndo_set_vf_spoofchk)(struct net_device *dev, int vf, u8 setting);
> > * int (*ndo_get_vf_config)(struct net_device *dev,
> > * int vf, struct ifla_vf_info *ivf);
> > * int (*ndo_set_vf_port)(struct net_device *dev, int vf,
> > @@ -900,6 +901,8 @@ struct net_device_ops {
> > int queue, u16 vlan, u8 qos);
> > int (*ndo_set_vf_tx_rate)(struct net_device *dev,
> > int vf, int rate);
> > + int (*ndo_set_vf_spoofchk)(struct net_device *dev,
> > + int vf, u8 setting);
>
> Why u8 and not bool?
This could be a bool, I believe Greg did a int just based on other
similar instances. Greg will definitely have a better knowledge and
possible future use instances which may justify an int.
>
> > int (*ndo_get_vf_config)(struct net_device *dev,
> > int vf,
> > struct ifla_vf_info *ivf);
> > diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> > index 39f8dd6..6535810 100644
> > --- a/net/core/rtnetlink.c
> > +++ b/net/core/rtnetlink.c
> > @@ -731,7 +731,8 @@ static inline int rtnl_vfinfo_size(const struct net_device *dev)
> > size += num_vfs *
> > (nla_total_size(sizeof(struct ifla_vf_mac)) +
> > nla_total_size(sizeof(struct ifla_vf_vlan)) +
> > - nla_total_size(sizeof(struct ifla_vf_tx_rate)));
> > + nla_total_size(sizeof(struct ifla_vf_tx_rate)) +
> > + nla_total_size(sizeof(struct ifla_vf_spoofchk)));
> > return size;
> > } else
> > return 0;
> > @@ -954,13 +955,19 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
> > struct ifla_vf_mac vf_mac;
> > struct ifla_vf_vlan vf_vlan;
> > struct ifla_vf_tx_rate vf_tx_rate;
> > + struct ifla_vf_spoofchk vf_spoofchk;
> > if (dev->netdev_ops->ndo_get_vf_config(dev, i, &ivi))
> > break;
> > - vf_mac.vf = vf_vlan.vf = vf_tx_rate.vf = ivi.vf;
> > + vf_mac.vf =
> > + vf_vlan.vf =
> > + vf_tx_rate.vf =
> > + vf_spoofchk.vf = ivi.vf;
> > +
> [...]
>
> The continuation lines should be indented. Or you could just write the
> assignments as multiple statements.
>
> Ben.
>
I agree. At least Greg and I can clean this up, if nothing else. I
will wait for Greg's thoughts/comments on your other observations before
re-spinning this patch.
Thanks Ben.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [net-next] iproute2: Add new command to IP link to enable/disable VF spoof check
From: Jeff Kirsher @ 2011-09-25 8:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Greg Rose, davem, netdev, gospo, Jeff Kirsher
From: Greg Rose <gregory.v.rose@intel.com>
Add IP link command parsing for VF spoof checking enable/disable
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
include/linux/if_link.h | 7 +++++++
ip/ipaddress.c | 6 ++++++
ip/iplink.c | 15 +++++++++++++++
man/man8/ip.8 | 4 +++-
4 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 304c44f..e421f60 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -277,6 +277,7 @@ enum {
IFLA_VF_MAC, /* Hardware queue specific attributes */
IFLA_VF_VLAN,
IFLA_VF_TX_RATE, /* TX Bandwidth Allocation */
+ IFLA_VF_SPOOFCHK, /* Spoof Checking on/off switch */
__IFLA_VF_MAX,
};
@@ -298,12 +299,18 @@ struct ifla_vf_tx_rate {
__u32 rate; /* Max TX bandwidth in Mbps, 0 disables throttling */
};
+struct ifla_vf_spoofchk {
+ __u32 vf;
+ __u32 setting;
+};
+
struct ifla_vf_info {
__u32 vf;
__u8 mac[32];
__u32 vlan;
__u32 qos;
__u32 tx_rate;
+ __u32 spoofchk;
};
/* VF ports management section
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 85f05a2..7e6ac50 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -197,6 +197,7 @@ static void print_vfinfo(FILE *fp, struct rtattr *vfinfo)
struct ifla_vf_mac *vf_mac;
struct ifla_vf_vlan *vf_vlan;
struct ifla_vf_tx_rate *vf_tx_rate;
+ struct ifla_vf_spoofchk *vf_spoofchk;
struct rtattr *vf[IFLA_VF_MAX+1];
SPRINT_BUF(b1);
@@ -210,6 +211,7 @@ static void print_vfinfo(FILE *fp, struct rtattr *vfinfo)
vf_mac = RTA_DATA(vf[IFLA_VF_MAC]);
vf_vlan = RTA_DATA(vf[IFLA_VF_VLAN]);
vf_tx_rate = RTA_DATA(vf[IFLA_VF_TX_RATE]);
+ vf_spoofchk = RTA_DATA(vf[IFLA_VF_SPOOFCHK]);
fprintf(fp, "\n vf %d MAC %s", vf_mac->vf,
ll_addr_n2a((unsigned char *)&vf_mac->mac,
@@ -220,6 +222,10 @@ static void print_vfinfo(FILE *fp, struct rtattr *vfinfo)
fprintf(fp, ", qos %d", vf_vlan->qos);
if (vf_tx_rate->rate)
fprintf(fp, ", tx rate %d (Mbps)", vf_tx_rate->rate);
+ if (vf_spoofchk->setting)
+ fprintf(fp, ", spoof checking on");
+ else
+ fprintf(fp, ", spoof checking off");
}
int print_linkinfo(const struct sockaddr_nl *who,
diff --git a/ip/iplink.c b/ip/iplink.c
index e5325a6..f4a5243 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -71,7 +71,10 @@ void iplink_usage(void)
fprintf(stderr, " [ alias NAME ]\n");
fprintf(stderr, " [ vf NUM [ mac LLADDR ]\n");
fprintf(stderr, " [ vlan VLANID [ qos VLAN-QOS ] ]\n");
+
fprintf(stderr, " [ rate TXRATE ] ] \n");
+
+ fprintf(stderr, " [ spoofchk { on | off} ] ] \n");
fprintf(stderr, " [ master DEVICE ]\n");
fprintf(stderr, " [ nomaster ]\n");
fprintf(stderr, " ip link show [ DEVICE | group GROUP ]\n");
@@ -228,6 +231,18 @@ int iplink_parse_vf(int vf, int *argcp, char ***argvp,
ivt.vf = vf;
addattr_l(&req->n, sizeof(*req), IFLA_VF_TX_RATE, &ivt, sizeof(ivt));
+ } else if (matches(*argv, "spoofchk") == 0) {
+ struct ifla_vf_spoofchk ivs;
+ NEXT_ARG();
+ if (matches(*argv, "on") == 0)
+ ivs.setting = 1;
+ else if (matches(*argv, "off") == 0)
+ ivs.setting = 0;
+ else
+ invarg("Invalid \"spoofchk\" value\n", *argv);
+ ivs.vf = vf;
+ addattr_l(&req->n, sizeof(*req), IFLA_VF_SPOOFCHK, &ivs, sizeof(ivs));
+
} else {
/* rewind arg */
PREV_ARG();
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 27993a4..cd7b97a 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -100,7 +100,9 @@ ip \- show / manipulate routing, devices, policy routing and tunnels
.B qos
.IR VLAN-QOS " ] ] ["
.B rate
-.IR TXRATE " ] |"
+.IR TXRATE " ] ["
+.B spoofchk { on | off }
+] |
.br
.B master
.IR DEVICE
--
1.7.6.2
^ permalink raw reply related
* Re: Bridge stays down until a port is added
From: Marc Haber @ 2011-09-25 8:25 UTC (permalink / raw)
To: netdev
In-Reply-To: <1316550027.1783.102.camel@dcbw.foobar.com>
On Tue, Sep 20, 2011 at 03:20:26PM -0500, Dan Williams wrote:
> On Sat, 2011-09-17 at 22:42 +0200, Marc Haber wrote:
> > On Thu, Aug 11, 2011 at 08:17:06AM -0700, Stephen Hemminger wrote:
> > In the IPv6 SLAAC case, the host tries start its radvd on the bridge
> > well before the first VM comes up, the radvd barfs since the interface
> > is not up, does not come up, and the VMs are without network. In this
> > case, it is needed to force the bridge into an UP state earlier so
> > that radvd can start.
>
> So why not start radvd when the first interface is added to the bridge?
With a daemon that waits for the bridge coming up? Or do you suggest
to add that complexity to VirtualBox or KVM's networking scripts?
> Or, really, make radvd aware of when the bridge comes up so it can
> handle this itself,
Ah, Adding complexity to radvd. A really nice idea.
Just for the record: For everybody else, this is a regression, since
things that used to work for years got broken in recent kernel versions.
Greetings
Marc, stopping this discussion now
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
^ permalink raw reply
* Re: [PATCH] IPVS: Removed unused conntrack sysctl entry
From: Julian Anastasov @ 2011-09-25 8:29 UTC (permalink / raw)
To: Simon Horman; +Cc: lvs-devel, netdev
In-Reply-To: <1316911743-28269-1-git-send-email-horms@verge.net.au>
Hello,
On Sun, 25 Sep 2011, Simon Horman wrote:
> This does not appear to be used anywhere.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
> net/netfilter/ipvs/ip_vs_ctl.c | 11 -----------
> 1 files changed, 0 insertions(+), 11 deletions(-)
>
> Julian, I cant see any users of this sysctl in the current code.
> Am I missing something?
It is used, see ip_vs_conntrack_enabled() in
include/net/ip_vs.h, after the netns changes the var is
named sysctl_conntrack.
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 36f4495..49befca 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -1605,14 +1605,6 @@ static struct ctl_table vs_vars[] = {
> .mode = 0644,
> .proc_handler = proc_do_defense_mode,
> },
> -#ifdef CONFIG_IP_VS_NFCT
> - {
> - .procname = "conntrack",
> - .maxlen = sizeof(int),
> - .mode = 0644,
> - .proc_handler = &proc_dointvec,
> - },
> -#endif
> {
> .procname = "secure_tcp",
> .maxlen = sizeof(int),
> @@ -3535,9 +3527,6 @@ int __net_init __ip_vs_control_init_sysctl(struct net *net)
> tbl[idx++].data = &ipvs->sysctl_am_droprate;
> tbl[idx++].data = &ipvs->sysctl_drop_entry;
> tbl[idx++].data = &ipvs->sysctl_drop_packet;
> -#ifdef CONFIG_IP_VS_NFCT
> - tbl[idx++].data = &ipvs->sysctl_conntrack;
> -#endif
> tbl[idx++].data = &ipvs->sysctl_secure_tcp;
> ipvs->sysctl_snat_reroute = 1;
> tbl[idx++].data = &ipvs->sysctl_snat_reroute;
> --
> 1.7.5.4
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: Forward Shared Patch
From: Julian Anastasov @ 2011-09-25 8:39 UTC (permalink / raw)
To: Simon Horman; +Cc: lvs-devel, netdev
In-Reply-To: <20110925011347.GB31019@verge.net.au>
Hello,
On Sun, 25 Sep 2011, Simon Horman wrote:
> Hi Julian,
>
> I am wondering if you have any interest in/objections to trying
> to merge your forward shared patch which allows an IPVS director
> to act as a router for realservers using the direct routing or tunnelling
> forwarding mechanisms.
>
> http://www.ssi.bg/~ja/#lvsgw
Such feature is already added to 2.6.33:
/proc/sys/net/ipv4/conf/*/accept_local
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox