From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Menage Subject: Re: [PATCH] per-cgroup tcp buffer limitation Date: Tue, 13 Sep 2011 11:09:03 -0700 Message-ID: References: <1315276556-10970-1-git-send-email-glommer@parallels.com> <4E664766.40200@parallels.com> <4E66A0A9.3060403@parallels.com> <4E68484A.4000201@parallels.com> <4E699341.9010606@parallels.com> <4E6E39DD.2040102@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4E6E39DD.2040102@parallels.com> Sender: owner-linux-mm@kvack.org To: Glauber Costa Cc: Greg Thelen , linux-kernel@vger.kernel.org, linux-mm@kvack.org, containers@lists.osdl.org, netdev@vger.kernel.org, xemul@parallels.com, "David S. Miller" , Hiroyouki Kamezawa , "Eric W. Biederman" , Suleiman Souhlal , Lennart Poettering List-Id: containers.vger.kernel.org On Mon, Sep 12, 2011 at 9:57 AM, Glauber Costa wrot= e: > > I think at this point there is at least consensus that this could very we= ll > 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 =3D) 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 =A0memory.{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 w= e > 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 ne= ed > 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, whe= n > 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756035Ab1IMSJZ (ORCPT ); Tue, 13 Sep 2011 14:09:25 -0400 Received: from mail-gx0-f170.google.com ([209.85.161.170]:48181 "EHLO mail-gx0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755870Ab1IMSJX convert rfc822-to-8bit (ORCPT ); Tue, 13 Sep 2011 14:09:23 -0400 MIME-Version: 1.0 In-Reply-To: <4E6E39DD.2040102@parallels.com> References: <1315276556-10970-1-git-send-email-glommer@parallels.com> <4E664766.40200@parallels.com> <4E66A0A9.3060403@parallels.com> <4E68484A.4000201@parallels.com> <4E699341.9010606@parallels.com> <4E6E39DD.2040102@parallels.com> From: Paul Menage Date: Tue, 13 Sep 2011 11:09:03 -0700 X-Google-Sender-Auth: iNhcG-N7z8inkoKJ9mtjQNJd9uk Message-ID: Subject: Re: [PATCH] per-cgroup tcp buffer limitation To: Glauber Costa Cc: Greg Thelen , linux-kernel@vger.kernel.org, linux-mm@kvack.org, containers@lists.osdl.org, netdev@vger.kernel.org, xemul@parallels.com, "David S. Miller" , Hiroyouki Kamezawa , "Eric W. Biederman" , Suleiman Souhlal , Lennart Poettering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 12, 2011 at 9:57 AM, Glauber Costa 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