linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov@parallels.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	<cgroups@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
	Li Zefan <lizefan@huawei.com>,
	"David S. Miller" <davem@davemloft.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Glauber Costa <glommer@gmail.com>,
	Pavel Emelianov <xemul@parallels.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Thelen <gthelen@google.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH RFC] memcg: revert kmem.tcp accounting
Date: Mon, 15 Sep 2014 11:36:00 +0400	[thread overview]
Message-ID: <20140915073600.GA11353@esperanza> (raw)
In-Reply-To: <20140912171809.GA24469@dhcp22.suse.cz>

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@suse.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

      parent reply	other threads:[~2014-09-15  7:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-12 15:26 [PATCH RFC] memcg: revert kmem.tcp accounting Vladimir Davydov
2014-09-12 17:18 ` Michal Hocko
2014-09-12 17:55   ` Tejun Heo
2014-09-12 21:43     ` Andrew Morton
2014-09-16  6:16       ` Tejun Heo
2014-09-15  7:42     ` Vladimir Davydov
2014-09-16  6:14       ` Tejun Heo
2014-09-16  8:38         ` Vladimir Davydov
2014-09-15  7:36   ` Vladimir Davydov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140915073600.GA11353@esperanza \
    --to=vdavydov@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=eric.dumazet@gmail.com \
    --cc=glommer@gmail.com \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizefan@huawei.com \
    --cc=mhocko@suse.cz \
    --cc=tj@kernel.org \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).