| 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
| ||
|
Message-ID: <4E6FAA1B.5020102@parallels.com> Date: Tue, 13 Sep 2011 16:08:11 -0300 From: Glauber Costa <glommer@...allels.com> To: Paul Menage <paul@...lmenage.org> 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 09/13/2011 03:46 PM, Paul Menage wrote: > On Tue, Sep 13, 2011 at 11:11 AM, Glauber Costa<glommer@...allels.com> 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 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
Powered by blists - more mailing lists