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
 
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:36:00 +0400
From:	Vladimir Davydov <vdavydov@...allels.com>
To:	Michal Hocko <mhocko@...e.cz>
CC:	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
	<cgroups@...r.kernel.org>, Tejun Heo <tj@...nel.org>,
	Li Zefan <lizefan@...wei.com>,
	"David S. Miller" <davem@...emloft.net>,
	Johannes Weiner <hannes@...xchg.org>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Glauber Costa <glommer@...il.com>,
	Pavel Emelianov <xemul@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Thelen <gthelen@...gle.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH RFC] memcg: revert kmem.tcp accounting

Hi Michal,

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?

In our product (OpenVZ) we have home-bred counters for many types of
resources, but we stopped setting limits for most of them, including tcp
buffers accounting, long time ago, and our customers don't set them
either. In the next product release we are going to drop them all and
use only mem, anon+swap, and kmem limits.

I don't know what was the reason to push this stuff, because I wasn't in
it at that time. From what I read from comments to the patches I found
it was something like the first step towards kmem accounting. However,
if we had fully functioning kmem accounting there would be no point in
this.

> 
> [...]
> 
> Anyway, more than welcome
> Acked-by: Michal Hocko <mhocko@...e.cz>

Thank you.

> 
> In case we happened to grow more users, which I hope hasn't happened, we
> would need to keep this around at least with the legacy cgroups API.

The whole CONFIG_MEMCG_KMEM is marked as DON'T ENABLE IT, BECAUSE IT
DOESN'T WORK (kudos to you). That's why I think we could probably close
our eye to wailing users if any.

Thanks,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists