From: Glauber Costa <glommer@parallels•com>
To: "Eric W. Biederman" <ebiederm@xmission•com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp•fujitsu.com>,
Linux Containers <containers@lists•osdl.org>,
<netdev@vger•kernel.org>, David Miller <davem@davemloft•net>,
Pavel Emelyanov <xemul@parallels•com>
Subject: Re: [RFC] per-containers tcp buffer limitation
Date: Thu, 25 Aug 2011 15:02:04 -0300 [thread overview]
Message-ID: <4E568E1C.3020308@parallels.com> (raw)
In-Reply-To: <m14o16qlq1.fsf@fess.ebiederm.org>
On 08/24/2011 11:16 PM, Eric W. Biederman wrote:
> KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp•fujitsu.com> writes:
>
>> On Wed, 24 Aug 2011 22:28:59 -0300
>> Glauber Costa<glommer@parallels•com> wrote:
>>
>>> On 08/24/2011 09:35 PM, Eric W. Biederman wrote:
>>>> Glauber Costa<glommer@parallels•com> writes:
>>> Hi Eric,
>>>
>>> Thanks for your attention.
>>>
>>> So, this that you propose was my first implementation. I ended up
>>> throwing it away after playing with it for a while.
>>>
>>> One of the first problems that arise from that, is that the sysctls are
>>> a tunable visible from inside the container. Those limits, however, are
>>> to be set from the outside world. The code is not much better than that
>>> either, and instead of creating new cgroup structures and linking them
>>> to the protocol, we end up doing it for net ns. We end up increasing
>>> structures just the same...
>
> You don't need to add a netns member to sockets.
But then you have to grow the netns structure itself somehow.
>
> But I do agree that there are odd permission issues with using the
> existing sysctls and making them per namespace.
>
> However almost everything I have seen with memory limits I have found
> very strange. They all seem like a very bad version of disabling memory
> over commits.
More or less. At least from our perspective, the only thing we're really
interested in capping are non-swappable resources. So you could not
overcommit anyway.
For the sockets/tcp case, it is an even easier case. The code as it is
today already allow you to define soft and hard memory limits: I am just
making it container-wide, instead of system-wide.
>>> Also, since we're doing resource control, it seems more natural to use
>>> cgroups. Now, the fact that there are no correlation whatsoever between
>>> cgroups and namespaces does bother me. But that's another story, much
>>> more broader and general than this patch.
>>>
>>
>> I think using cgroup makes sense. A question in mind is whehter it is
>> better to integrate this kind of 'memory usage' controls to memcg or
>> not.
>
> Maybe. When sockets start getting a cgroup member I start wondering,
> how many cgroup members will sockets potentially belong to.
>
>> How do you think ? IMHO, having cgroup per class of object is messy.
>> ...
>> How about adding
>> memory.tcp_mem
>> to memcg ?
>>
>> Or, adding kmem cgroup ?
>>
>>> About overhead, since this is the first RFC, I did not care about
>>> measuring. However, it seems trivial to me to guarantee that at least
>>> that it won't impose a significant performance penalty when it is
>>> compiled out. If we're moving forward with this implementation, I will
>>> include data in the next release so we can discuss in this basis.
>>>
>>
>> IMHO, you should show performance number even if RFC. Then, people will
>> see patch with more interests.
>
> And also compiled out doesn't really count. Cgroups are something you
> want people to compile into distributions for the common case, and you
> don't want to impose a noticeable performance penalty for the common
> case.
Absolutely agreed.
next prev parent reply other threads:[~2011-08-25 18:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 22:54 [RFC] per-containers tcp buffer limitation Glauber Costa
2011-08-25 0:35 ` Eric W. Biederman
2011-08-25 1:28 ` Glauber Costa
2011-08-25 1:49 ` KAMEZAWA Hiroyuki
2011-08-25 2:16 ` Eric W. Biederman
[not found] ` <m14o16qlq1.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2011-08-25 12:55 ` Daniel Wagner
2011-08-25 15:05 ` Chris Friesen
2011-08-25 15:44 ` Stephen Hemminger
2011-08-25 18:11 ` Glauber Costa
2011-08-25 18:33 ` Daniel Wagner
2011-08-25 18:45 ` Daniel Wagner
2011-08-25 18:27 ` Daniel Wagner
[not found] ` <4E56942A.3080905-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
2011-08-27 23:39 ` Matthew Helsley
2011-08-28 6:09 ` David Miller
2011-08-25 18:02 ` Glauber Costa [this message]
2011-08-25 18:05 ` 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=4E568E1C.3020308@parallels.com \
--to=glommer@parallels$(echo .)com \
--cc=containers@lists$(echo .)osdl.org \
--cc=davem@davemloft$(echo .)net \
--cc=ebiederm@xmission$(echo .)com \
--cc=kamezawa.hiroyu@jp$(echo .)fujitsu.com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=xemul@parallels$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox