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  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]
Date:	Mon, 15 Sep 2014 11:42:57 +0400
From:	Vladimir Davydov <>
To:	Tejun Heo <>
CC:	Michal Hocko <>, <>,
	<>, <>,
	Li Zefan <>,
	"David S. Miller" <>,
	"Johannes Weiner" <>,
	Kamezawa Hiroyuki <>,
	Glauber Costa <>,
	"Pavel Emelianov" <>,
	Andrew Morton <>,
	Greg Thelen <>,
	Eric Dumazet <>,
	"Eric W. Biederman" <>
Subject: Re: [PATCH RFC] memcg: revert kmem.tcp accounting

Hi Tejun,

On Sat, Sep 13, 2014 at 02:55:16AM +0900, Tejun Heo wrote:
> Hello, guys.
> On Fri, Sep 12, 2014 at 07:18:09PM +0200, Michal Hocko wrote:
> > On Fri 12-09-14 19:26:58, Vladimir Davydov wrote:
> > > memory.kmem.tcp.limit_in_bytes works as the system-wide tcp_mem sysctl,
> > > but per memory cgroup. While the existence of the latter is justified
> > > (it prevents the system from becoming unusable due to uncontrolled tcp
> > > buffers growth) the reason why we need such a knob in containers isn't
> > > clear to me.
> > 
> > Parallels was the primary driver for this change. I haven't heard of
> > anybody using the feature other than Parallels. I also remember there
> > was a strong push for this feature before it was merged besides there
> > were some complains at the time. I do not remember details (and I am
> > one half way gone for the weekend now) so I do not have pointers to
> > discussions.
> > 
> > I would love to get rid of the code and I am pretty sure that networking
> > people would love this go even more. I didn't plan to provide kmem.tcp.*
> > knobs for the cgroups v2 interface but getting rid of it altogether
> > sounds even better. I am just not sure whether some additional users
> > grown over time.
> > Nevertheless I am really curious. What has changed that Parallels is not
> > interested in kmem.tcp anymore?
> So, I'd love to see this happen too but I don't think we can do this.
> People use published interface.  The usages might be utterly one-off
> and mental but let's please not underestimate the sometimes senseless
> creativity found in the wild.  We simply can't remove a bunch of
> control knobs like this.

We definitely can't remove something properly operating and widely used,
but kmem limits are not working and never worked properly due to lack of
kmem shrinkers, and furthermore CONFIG_MEMCG_KMEM, which tcp accounting
is enabled by, is marked as UNDER DEVELOPMENT.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists