netdev - Re: [PATCH] per-cgroup tcp buffer limitation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALdu-PC7ESSUHuF4vfVoRFFfkaBt1V28rGW3-O5pT3WtegAh4g@mail.gmail.com>
Date:	Tue, 13 Sep 2011 11:09:03 -0700
From:	Paul Menage <paul@...lmenage.org>
To:	Glauber Costa <glommer@...allels.com>
Cc:	Greg Thelen <gthelen@...gle.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, containers@...ts.osdl.org,
	netdev@...r.kernel.org, xemul@...allels.com,
	"David S. Miller" <davem@...emloft.net>,
	Hiroyouki Kamezawa <kamezawa.hiroyu@...fujitsu.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Suleiman Souhlal <suleiman@...gle.com>,
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: [PATCH] per-cgroup tcp buffer limitation

On Mon, Sep 12, 2011 at 9:57 AM, Glauber Costa <glommer@...allels.com> wrote:
>
> I think at this point there is at least consensus that this could very well
> live in memcg, right ?

Yes, it looks that way.

>> This is definitely an improvement, but I'd say it's not enough. I
>> think we should consider something like:
>
> One step at a time =)

Yes, as far as design and initial implementation goes - but the full
plan has to be figured out before anything gets committed to mainline,
given the stability guarantees that implies.

>> - the 'active' control determines whether (all) child cgroups will
>> have  memory.{limit,usage}_in_bytes files, or
>> memory.{kernel,user}_{limit,usage}_in_bytes files
>> - kernel memory will be charged either against 'kernel' or 'total'
>> depending on the value of unified
>
> You mean for display/pressure purposes, right? Internally, I think once we
> have kernel memory, we always charge it to kernel memory, regardless of
> anything else. The value in unified field will only take place when we need
> to grab this value.
>
> I don't personally see a reason for not having all files present at all
> times.

There's pretty much only one reason - avoiding the overhead of
maintaining multiple counters.

Each set of counters (user, kernel, total) will have its own locks,
contention and other overheads to keep up to date. If userspace
doesn't care about one or two of the three, then that's mostly wasted.

Now it might be that the accounting of all three can be done with
little more overhead than that required to update just a split view or
just a unified view, in which case there's much less argument against
simplifying and tracking/charging/limiting all three.

>
> It is overly flexible if we're exposing these counters and expecting the
> user to do anything with them. It is perfectly fine if a single file, when
> read, displays this information as statistics.
>

When I proposed this, I guess I was envisioning that most of the
counters (e.g. things like TCP buffers or general network buffers)
would be primarily for stats, since the admin probably only cares
about total memory usage.

The main point of this was to allow people who want to do something
like tracking/limiting TCP buffer usage specifically per-cgroup to do
so, without having any performance impact on the regular users.

Paul
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html