From: Vladimir Davydov <vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
Cc: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>,
Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Kamezawa Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
Motohiro Kosaki
<Motohiro.Kosaki-gkcJ3tX5bYHQFUHtdCDX3A@public.gmane.org>,
Glauber Costa <glommer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Pavel Emelianov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
Konstantin Khorenko
<khorenko-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
LKML-MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
LKML-cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC] memory cgroup: my thoughts on memsw
Date: Wed, 17 Sep 2014 19:59:15 +0400 [thread overview]
Message-ID: <20140917155915.GB5065@esperanza> (raw)
In-Reply-To: <20140915191435.GA8950-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
Hi Johannes,
On Mon, Sep 15, 2014 at 03:14:35PM -0400, Johannes Weiner wrote:
> > Finally, my understanding (may be crazy!) how the things should be
> > configured. Just like now, there should be mem_cgroup->res accounting
> > and limiting total user memory (cache+anon) usage for processes inside
> > cgroups. This is where there's nothing to do. However, mem_cgroup->memsw
> > should be reworked to account *only* memory that may be swapped out plus
> > memory that has been swapped out (i.e. swap usage).
>
> But anon pages are not a resource, they are a swap space liability.
> Think of virtual memory vs. physical pages - the use of one does not
> necessarily result in the use of the other. Without memory pressure,
> anonymous pages do not consume swap space.
>
> What we *should* be accounting and limiting here is the actual finite
> resource: swap space. Whenever we try to swap a page, its owner
> should be charged for the swap space - or the swapout be rejected.
I've been thinking quite a bit on the problem, and finally I believe
you're right: a separate swap limit would be better than anon+swap.
Provided we make the OOM-killer kill cgroups that exceed their soft
limit and can't be reclaimed, it will solve the problem with soft limits
I described above.
Besides, comparing to anon+swap, swap limit would be more efficient (we
only need to charge one res counter, not two) and understandable to
users (it's simple to setup a limit for both kinds of resources then,
because they never mix).
Finally, we could transfer user configuration from cgroup v1 to v2
easily: just setup swap.limit to be equal to memsw.limit-mem.limit; it
won't be exactly the same, but I bet nobody will notice any difference.
So, at least for now, I vote for moving from mem+swap to swap
accounting.
Thanks,
Vladimir
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Davydov <vdavydov@parallels.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>, Greg Thelen <gthelen@google.com>,
Hugh Dickins <hughd@google.com>,
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Motohiro Kosaki <Motohiro.Kosaki@us.fujitsu.com>,
Glauber Costa <glommer@gmail.com>, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Pavel Emelianov <xemul@parallels.com>,
Konstantin Khorenko <khorenko@parallels.com>,
LKML-MM <linux-mm@kvack.org>,
LKML-cgroups <cgroups@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] memory cgroup: my thoughts on memsw
Date: Wed, 17 Sep 2014 19:59:15 +0400 [thread overview]
Message-ID: <20140917155915.GB5065@esperanza> (raw)
In-Reply-To: <20140915191435.GA8950@cmpxchg.org>
Hi Johannes,
On Mon, Sep 15, 2014 at 03:14:35PM -0400, Johannes Weiner wrote:
> > Finally, my understanding (may be crazy!) how the things should be
> > configured. Just like now, there should be mem_cgroup->res accounting
> > and limiting total user memory (cache+anon) usage for processes inside
> > cgroups. This is where there's nothing to do. However, mem_cgroup->memsw
> > should be reworked to account *only* memory that may be swapped out plus
> > memory that has been swapped out (i.e. swap usage).
>
> But anon pages are not a resource, they are a swap space liability.
> Think of virtual memory vs. physical pages - the use of one does not
> necessarily result in the use of the other. Without memory pressure,
> anonymous pages do not consume swap space.
>
> What we *should* be accounting and limiting here is the actual finite
> resource: swap space. Whenever we try to swap a page, its owner
> should be charged for the swap space - or the swapout be rejected.
I've been thinking quite a bit on the problem, and finally I believe
you're right: a separate swap limit would be better than anon+swap.
Provided we make the OOM-killer kill cgroups that exceed their soft
limit and can't be reclaimed, it will solve the problem with soft limits
I described above.
Besides, comparing to anon+swap, swap limit would be more efficient (we
only need to charge one res counter, not two) and understandable to
users (it's simple to setup a limit for both kinds of resources then,
because they never mix).
Finally, we could transfer user configuration from cgroup v1 to v2
easily: just setup swap.limit to be equal to memsw.limit-mem.limit; it
won't be exactly the same, but I bet nobody will notice any difference.
So, at least for now, I vote for moving from mem+swap to swap
accounting.
Thanks,
Vladimir
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Davydov <vdavydov@parallels.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>, Greg Thelen <gthelen@google.com>,
Hugh Dickins <hughd@google.com>,
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Motohiro Kosaki <Motohiro.Kosaki@us.fujitsu.com>,
Glauber Costa <glommer@gmail.com>, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Pavel Emelianov <xemul@parallels.com>,
Konstantin Khorenko <khorenko@parallels.com>,
LKML-MM <linux-mm@kvack.org>,
LKML-cgroups <cgroups@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] memory cgroup: my thoughts on memsw
Date: Wed, 17 Sep 2014 19:59:15 +0400 [thread overview]
Message-ID: <20140917155915.GB5065@esperanza> (raw)
In-Reply-To: <20140915191435.GA8950@cmpxchg.org>
Hi Johannes,
On Mon, Sep 15, 2014 at 03:14:35PM -0400, Johannes Weiner wrote:
> > Finally, my understanding (may be crazy!) how the things should be
> > configured. Just like now, there should be mem_cgroup->res accounting
> > and limiting total user memory (cache+anon) usage for processes inside
> > cgroups. This is where there's nothing to do. However, mem_cgroup->memsw
> > should be reworked to account *only* memory that may be swapped out plus
> > memory that has been swapped out (i.e. swap usage).
>
> But anon pages are not a resource, they are a swap space liability.
> Think of virtual memory vs. physical pages - the use of one does not
> necessarily result in the use of the other. Without memory pressure,
> anonymous pages do not consume swap space.
>
> What we *should* be accounting and limiting here is the actual finite
> resource: swap space. Whenever we try to swap a page, its owner
> should be charged for the swap space - or the swapout be rejected.
I've been thinking quite a bit on the problem, and finally I believe
you're right: a separate swap limit would be better than anon+swap.
Provided we make the OOM-killer kill cgroups that exceed their soft
limit and can't be reclaimed, it will solve the problem with soft limits
I described above.
Besides, comparing to anon+swap, swap limit would be more efficient (we
only need to charge one res counter, not two) and understandable to
users (it's simple to setup a limit for both kinds of resources then,
because they never mix).
Finally, we could transfer user configuration from cgroup v1 to v2
easily: just setup swap.limit to be equal to memsw.limit-mem.limit; it
won't be exactly the same, but I bet nobody will notice any difference.
So, at least for now, I vote for moving from mem+swap to swap
accounting.
Thanks,
Vladimir
next prev parent reply other threads:[~2014-09-17 15:59 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 14:30 [RFC] memory cgroup: my thoughts on memsw Vladimir Davydov
2014-09-04 14:30 ` Vladimir Davydov
2014-09-04 14:30 ` Vladimir Davydov
2014-09-04 22:03 ` Kamezawa Hiroyuki
2014-09-04 22:03 ` Kamezawa Hiroyuki
2014-09-04 22:03 ` Kamezawa Hiroyuki
[not found] ` <5408E1CD.3090004-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2014-09-05 8:28 ` Vladimir Davydov
2014-09-05 8:28 ` Vladimir Davydov
2014-09-05 8:28 ` Vladimir Davydov
2014-09-05 14:20 ` Kamezawa Hiroyuki
2014-09-05 14:20 ` Kamezawa Hiroyuki
2014-09-05 14:20 ` Kamezawa Hiroyuki
2014-09-05 16:00 ` Vladimir Davydov
2014-09-05 16:00 ` Vladimir Davydov
2014-09-05 23:15 ` Kamezawa Hiroyuki
2014-09-05 23:15 ` Kamezawa Hiroyuki
2014-09-08 11:01 ` Vladimir Davydov
2014-09-08 11:01 ` Vladimir Davydov
2014-09-08 13:53 ` Kamezawa Hiroyuki
2014-09-08 13:53 ` Kamezawa Hiroyuki
2014-09-09 10:39 ` Vladimir Davydov
2014-09-09 10:39 ` Vladimir Davydov
2014-09-11 2:04 ` Kamezawa Hiroyuki
2014-09-11 2:04 ` Kamezawa Hiroyuki
2014-09-11 8:23 ` Vladimir Davydov
2014-09-11 8:23 ` Vladimir Davydov
2014-09-11 8:53 ` Kamezawa Hiroyuki
2014-09-11 8:53 ` Kamezawa Hiroyuki
[not found] ` <54116324.7000200-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2014-09-11 9:50 ` Vladimir Davydov
2014-09-11 9:50 ` Vladimir Davydov
2014-09-11 9:50 ` Vladimir Davydov
2014-09-10 12:01 ` Vladimir Davydov
2014-09-10 12:01 ` Vladimir Davydov
2014-09-11 1:22 ` Kamezawa Hiroyuki
2014-09-11 1:22 ` Kamezawa Hiroyuki
2014-09-11 7:03 ` Vladimir Davydov
2014-09-11 7:03 ` Vladimir Davydov
2014-09-15 19:14 ` Johannes Weiner
2014-09-15 19:14 ` Johannes Weiner
2014-09-16 1:34 ` Kamezawa Hiroyuki
2014-09-16 1:34 ` Kamezawa Hiroyuki
[not found] ` <20140915191435.GA8950-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2014-09-17 15:59 ` Vladimir Davydov [this message]
2014-09-17 15:59 ` Vladimir Davydov
2014-09-17 15:59 ` Vladimir Davydov
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=20140917155915.GB5065@esperanza \
--to=vdavydov-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=Motohiro.Kosaki-gkcJ3tX5bYHQFUHtdCDX3A@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=glommer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=khorenko-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.