From: Daniel Wagner <wagi-kQCPcA+X3s7YtjvyW6yDsg@public•gmane.org>
To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public•gmane.org>
Cc: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public•gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public•gmane.org,
Linux Containers
<containers-qjLDD68F18O7TbgM5vRIOg@public•gmane.org>,
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public•gmane.org>
Subject: Re: [RFC] per-containers tcp buffer limitation
Date: Thu, 25 Aug 2011 14:55:39 +0200 [thread overview]
Message-ID: <4E56464B.4070304@monom.org> (raw)
In-Reply-To: <m14o16qlq1.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
Hi
On 08/25/2011 04:16 AM, Eric W. Biederman wrote:
> KAMEZAWA Hiroyuki<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public•gmane.org> writes:
>
>> On Wed, 24 Aug 2011 22:28:59 -0300
>> Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public•gmane.org> wrote:
>>
>>> On 08/24/2011 09:35 PM, Eric W. Biederman wrote:
>>>> Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public•gmane.org> 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 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.
Please apply the same rules for not cursing my family no further then
the 3rd generation for my idea:
I'd like to solve a use case where it is necessary to count all bytes
transmitted and received by an application [1]. So far I have found two
unsatisfying solution for it. The first one is to hook into libc and
count the bytes there. I don't think I have to say I don't like this.
The second idea was to use the trick Google has used for Android [2].
They add a hook into __sock_sendmsg and __sock_recvmsg and then count
the bytes per UID. To get this working all application have to use an
unique UID. So not very nice either.
After reading a bit up on cgroup I think that would be the right place
to count the traffic. Unfortunately, with net_cls I can count the
outgoing traffic but not the incoming one. If I understood Glauber
approach correctly adding some statistic counters would be easy to do.
Of course I don't know the impact of this.
thanks,
daniel
[1]
http://lists.freedesktop.org/archives/systemd-devel/2011-August/003093.html
[2]
http://xf.iksaif.net/dev/android/android-2.6.29-to-2.6.32/0083-uidstat-Adding-uid-stat-driver-to-collect-network-st.patch
next prev parent reply other threads:[~2011-08-25 12:55 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 [this message]
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
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=4E56464B.4070304@monom.org \
--to=wagi-kqcpca+x3s7ytjvyw6ydsg@public$(echo .)gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public$(echo .)gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public$(echo .)gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public$(echo .)gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=xemul-bzQdu9zFT3WakBO8gow8eQ@public$(echo .)gmane.org \
/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