From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH] per-cgroup tcp buffer limitation Date: Tue, 13 Sep 2011 16:08:11 -0300 Message-ID: <4E6FAA1B.5020102@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> <4E6F9CC4.2000601@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org To: Paul Menage 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 09/13/2011 03:46 PM, Paul Menage wrote: > On Tue, Sep 13, 2011 at 11:11 AM, Glauber Costa wrote: >> >> What if they are all updated under the same lock ? > > Right, that would be the kind of optimization that would remove the > need for worrying about whether or not to account it. It would > probably mean creating some memcg-specific structures like > res-counters that could handle multiple values, since you'd need to > update both the kernel charge and the total charge, in this cgroup > *and* its ancestors. > > Paul If we do that, we may have to commit to an intermediary user interface - with controls to to determine if kernel memory is billed to kernel or total, a enable/disable file, just to later render it pointless by a new optimization - that we seem to agree that seems possible. I think it is preferred to always assume kernel memory is accounted to the kernel, and when we optimize it, no changes are made to what's exposed to userspace. -- 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 S932370Ab1IMTJd (ORCPT ); Tue, 13 Sep 2011 15:09:33 -0400 Received: from mx2.parallels.com ([64.131.90.16]:56891 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932092Ab1IMTJc (ORCPT ); Tue, 13 Sep 2011 15:09:32 -0400 Message-ID: <4E6FAA1B.5020102@parallels.com> Date: Tue, 13 Sep 2011 16:08:11 -0300 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Paul Menage CC: Greg Thelen , , , , , , "David S. Miller" , Hiroyouki Kamezawa , "Eric W. Biederman" , Suleiman Souhlal , Lennart Poettering Subject: Re: [PATCH] per-cgroup tcp buffer limitation 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> <4E6F9CC4.2000601@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [187.106.51.14] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/13/2011 03:46 PM, Paul Menage wrote: > On Tue, Sep 13, 2011 at 11:11 AM, Glauber Costa wrote: >> >> What if they are all updated under the same lock ? > > Right, that would be the kind of optimization that would remove the > need for worrying about whether or not to account it. It would > probably mean creating some memcg-specific structures like > res-counters that could handle multiple values, since you'd need to > update both the kernel charge and the total charge, in this cgroup > *and* its ancestors. > > Paul If we do that, we may have to commit to an intermediary user interface - with controls to to determine if kernel memory is billed to kernel or total, a enable/disable file, just to later render it pointless by a new optimization - that we seem to agree that seems possible. I think it is preferred to always assume kernel memory is accounted to the kernel, and when we optimize it, no changes are made to what's exposed to userspace. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH] per-cgroup tcp buffer limitation Date: Tue, 13 Sep 2011 16:08:11 -0300 Message-ID: <4E6FAA1B.5020102@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> <4E6F9CC4.2000601@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: Greg Thelen , , , , , , "David S. Miller" , Hiroyouki Kamezawa , "Eric W. Biederman" , Suleiman Souhlal , Lennart Poettering To: Paul Menage Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org List-Id: netdev.vger.kernel.org On 09/13/2011 03:46 PM, Paul Menage wrote: > On Tue, Sep 13, 2011 at 11:11 AM, Glauber Costa wrote: >> >> What if they are all updated under the same lock ? > > Right, that would be the kind of optimization that would remove the > need for worrying about whether or not to account it. It would > probably mean creating some memcg-specific structures like > res-counters that could handle multiple values, since you'd need to > update both the kernel charge and the total charge, in this cgroup > *and* its ancestors. > > Paul If we do that, we may have to commit to an intermediary user interface - with controls to to determine if kernel memory is billed to kernel or total, a enable/disable file, just to later render it pointless by a new optimization - that we seem to agree that seems possible. I think it is preferred to always assume kernel memory is accounted to the kernel, and when we optimize it, no changes are made to what's exposed to userspace. -- 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