Re: [PATCH] per-cgroup tcp buffer limitation

[Paul Menage <paul@paulmenage.org>]

On Mon, Sep 12, 2011 at 9:57 AM, Glauber Costa <glommer@parallels.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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>