[RFC/Review] Prevent network namespace memory exhaution

John Johansen john.johansen at canonical.com
Fri Mar 25 14:30:24 UTC 2011


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.




More information about the kernel-team mailing list