[RFC/Review] Prevent network namespace memory exhaution

[John Johansen]

On 03/25/2011 07:36 AM, Tim Gardner wrote:
> On 03/25/2011 08:30 AM, John Johansen wrote:
>> On 03/25/2011 06:49 AM, Tim Gardner wrote:
>>> On 03/25/2011 07:16 AM, John Johansen wrote:
>>>
>>>>> I'm still not convinced that CONFIG_NET_NS=n isn't the best
>>>>> solution, despite the complaints that change might elicit. I'd
>>>>> like to hear from the consumers of network name spaces about
>>>>> how they are using the feature, and possible workarounds if it
>>>>> were to go away.
>>>>>
>>>> That is the solution I would like but I think that at least for
>>>> the server that is going to be problematic. Container are seeing
>>>> a lot of use.
>>>>
>>>
>>> While containers in general are in use, are network name spaces
>>> pro-actively being used? Is there some workload that is _dependent_
>>> on NET_NS ? I'm not proposing that we disable containers or other
>>> name space features, only NET_NS.
>>>
>> I don't know the answer to that, it is worth exploring.  It is
>> pro-actively being used in that some applications are requesting the
>> CLONE_NEWNET flag, and I have seen container workloads that could
>> claim to require NET_NS (essentially replacing virtual machines with
>> containers) but I am not sure what kernel they were using.  I
>> actually would like to turn NET_NS off too, my concern is that it is
>> a regression of the feature that some (unquantifiable) set of users
>> are using.
>>
>>>> If we were to go with an SRU of this I would lean towards the
>>>> smaller patchset that is enough to prevent memory being eaten (7
>>>> of the 13), and then if speed is a problem the remain 6 could be
>>>> SRUed afterwards.
>>>
>>> I'm not keen on releasing a kernel that reduces connection
>>> setup/teardown by an order of magnitude. Surely this'll have an
>>> adverse impact on web servers and the like.
>>>
>> Neither am I but, but my perhaps flawed understanding was it should
>> only affect the connection setup/teardown if a new network namespace
>> is being created, and I doubt most use cases actually do this.  This
>> is actually something we should get a better handle on, what work
>> loads that use NET_NS are noticeably impacted by this.
> 
> Well, there is an alternative for those folks that _are_ dependent on NET_NS:
> 
> sudo apt-get install linux-image-server-lts-backport-maverick
> 
oh right, that convinces me.  Turn it off.