All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov@parallels.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>, Michal Hocko <mhocko@suse.cz>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 1/4] mm: memcontrol: uncharge pages on swapout
Date: Wed, 22 Oct 2014 19:37:25 +0400	[thread overview]
Message-ID: <20141022153725.GY16496@esperanza> (raw)
In-Reply-To: <20141022132038.GB17161@phnom.home.cmpxchg.org>

On Wed, Oct 22, 2014 at 09:20:38AM -0400, Johannes Weiner wrote:
> On Wed, Oct 22, 2014 at 12:33:53PM +0400, Vladimir Davydov wrote:
> > On Tue, Oct 21, 2014 at 05:03:28PM -0400, Johannes Weiner wrote:
> > > On Tue, Oct 21, 2014 at 04:52:52PM +0400, Vladimir Davydov wrote:
> > > > On Mon, Oct 20, 2014 at 11:22:09AM -0400, Johannes Weiner wrote:
> > > > > mem_cgroup_swapout() is called with exclusive access to the page at
> > > > > the end of the page's lifetime.  Instead of clearing the PCG_MEMSW
> > > > > flag and deferring the uncharge, just do it right away.  This allows
> > > > > follow-up patches to simplify the uncharge code.
> > > > > 
> > > > > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> > > > > ---
> > > > >  mm/memcontrol.c | 17 +++++++++++++----
> > > > >  1 file changed, 13 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > > > index bea3fddb3372..7709f17347f3 100644
> > > > > --- a/mm/memcontrol.c
> > > > > +++ b/mm/memcontrol.c
> > > > > @@ -5799,6 +5799,7 @@ static void __init enable_swap_cgroup(void)
> > > > >   */
> > > > >  void mem_cgroup_swapout(struct page *page, swp_entry_t entry)
> > > > >  {
> > > > > +	struct mem_cgroup *memcg;
> > > > >  	struct page_cgroup *pc;
> > > > >  	unsigned short oldid;
> > > > >  
> > > > > @@ -5815,13 +5816,21 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t entry)
> > > > >  		return;
> > > > >  
> > > > >  	VM_BUG_ON_PAGE(!(pc->flags & PCG_MEMSW), page);
> > > > > +	memcg = pc->mem_cgroup;
> > > > >  
> > > > > -	oldid = swap_cgroup_record(entry, mem_cgroup_id(pc->mem_cgroup));
> > > > > +	oldid = swap_cgroup_record(entry, mem_cgroup_id(memcg));
> > > > >  	VM_BUG_ON_PAGE(oldid, page);
> > > > > +	mem_cgroup_swap_statistics(memcg, true);
> > > > >  
> > > > > -	pc->flags &= ~PCG_MEMSW;
> > > > > -	css_get(&pc->mem_cgroup->css);
> > > > > -	mem_cgroup_swap_statistics(pc->mem_cgroup, true);
> > > > > +	pc->flags = 0;
> > > > > +
> > > > > +	if (!mem_cgroup_is_root(memcg))
> > > > > +		page_counter_uncharge(&memcg->memory, 1);
> > > > 
> > > > AFAIU it removes batched uncharge of swapped out pages, doesn't it? Will
> > > > it affect performance?
> > > 
> > > During swapout and with lockless page counters?  I don't think so.
> > 
> > How is this different from page cache out? I mean, we can have a lot of
> > pages in the swap cache that have already been swapped out, and are
> > waiting to be unmapped, uncharged, and freed, just like usual page
> > cache. Why do we use batching for file cache pages then?
> 
> The batching is mostly for munmap().  We do it for reclaim because
> it's convenient, but I don't think an extra word per struct page to
> batch one, sometimes a few, locked subtractions per swapped out page
> is a reasonable trade-off.
> 
> > > > Besides, it looks asymmetric with respect to the page cache uncharge
> > > > path, where we still defer uncharge to mem_cgroup_uncharge_list(), and I
> > > > personally rather dislike this asymmetry.
> > > 
> > > The asymmetry is inherent in the fact that we mave memory and
> > > memory+swap accounting, and here a memory charge is transferred out to
> > > swap.  Before, the asymmetry was in mem_cgroup_uncharge_list() where
> > > we separate out memory and memsw pages (which the next patch fixes).
> > 
> > I agree that memsw is inherently asymmetric, but IMO it isn't the case
> > for swap *cache* vs page *cache*. We handle them similarly - removing
> > from a mapping, uncharging, freeing. If one wants batching, why
> > shouldn't the other?
> 
> It has to be worth it in practical terms.  You can argue symmetry
> between swap cache and page cache, but swapping simply is a much
> colder path than reclaiming page cache.  Our reclaim algorithm avoids
> it like the plague.
> 
> > > So nothing changed, the ugliness was just moved around.  I actually
> > > like it better now that it's part of the swap controller, because
> > > that's where the nastiness actually comes from.  This will all go away
> > > when we account swap separately.  Then, swapped pages can keep their
> > > memory charge until mem_cgroup_uncharge() again and the swap charge
> > > will be completely independent from it.  This reshuffling is just
> > > necessary because it allows us to get rid of the per-page flag.
> > 
> > Do you mean that swap cache uncharge batching will be back soon?
> 
> Well, yes, once we switch from memsw to a separate swap couter, it
> comes automatically.  Pages no longer carry two charges, and so the
> uncharging of pages doesn't have to distinguish between swapped out
> pages and other pages anymore.

With this in mind,

Acked-by: Vladimir Davydov <vdavydov@parallels.com>

--
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: Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>, Michal Hocko <mhocko@suse.cz>,
	<linux-mm@kvack.org>, <cgroups@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [patch 1/4] mm: memcontrol: uncharge pages on swapout
Date: Wed, 22 Oct 2014 19:37:25 +0400	[thread overview]
Message-ID: <20141022153725.GY16496@esperanza> (raw)
In-Reply-To: <20141022132038.GB17161@phnom.home.cmpxchg.org>

On Wed, Oct 22, 2014 at 09:20:38AM -0400, Johannes Weiner wrote:
> On Wed, Oct 22, 2014 at 12:33:53PM +0400, Vladimir Davydov wrote:
> > On Tue, Oct 21, 2014 at 05:03:28PM -0400, Johannes Weiner wrote:
> > > On Tue, Oct 21, 2014 at 04:52:52PM +0400, Vladimir Davydov wrote:
> > > > On Mon, Oct 20, 2014 at 11:22:09AM -0400, Johannes Weiner wrote:
> > > > > mem_cgroup_swapout() is called with exclusive access to the page at
> > > > > the end of the page's lifetime.  Instead of clearing the PCG_MEMSW
> > > > > flag and deferring the uncharge, just do it right away.  This allows
> > > > > follow-up patches to simplify the uncharge code.
> > > > > 
> > > > > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> > > > > ---
> > > > >  mm/memcontrol.c | 17 +++++++++++++----
> > > > >  1 file changed, 13 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > > > index bea3fddb3372..7709f17347f3 100644
> > > > > --- a/mm/memcontrol.c
> > > > > +++ b/mm/memcontrol.c
> > > > > @@ -5799,6 +5799,7 @@ static void __init enable_swap_cgroup(void)
> > > > >   */
> > > > >  void mem_cgroup_swapout(struct page *page, swp_entry_t entry)
> > > > >  {
> > > > > +	struct mem_cgroup *memcg;
> > > > >  	struct page_cgroup *pc;
> > > > >  	unsigned short oldid;
> > > > >  
> > > > > @@ -5815,13 +5816,21 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t entry)
> > > > >  		return;
> > > > >  
> > > > >  	VM_BUG_ON_PAGE(!(pc->flags & PCG_MEMSW), page);
> > > > > +	memcg = pc->mem_cgroup;
> > > > >  
> > > > > -	oldid = swap_cgroup_record(entry, mem_cgroup_id(pc->mem_cgroup));
> > > > > +	oldid = swap_cgroup_record(entry, mem_cgroup_id(memcg));
> > > > >  	VM_BUG_ON_PAGE(oldid, page);
> > > > > +	mem_cgroup_swap_statistics(memcg, true);
> > > > >  
> > > > > -	pc->flags &= ~PCG_MEMSW;
> > > > > -	css_get(&pc->mem_cgroup->css);
> > > > > -	mem_cgroup_swap_statistics(pc->mem_cgroup, true);
> > > > > +	pc->flags = 0;
> > > > > +
> > > > > +	if (!mem_cgroup_is_root(memcg))
> > > > > +		page_counter_uncharge(&memcg->memory, 1);
> > > > 
> > > > AFAIU it removes batched uncharge of swapped out pages, doesn't it? Will
> > > > it affect performance?
> > > 
> > > During swapout and with lockless page counters?  I don't think so.
> > 
> > How is this different from page cache out? I mean, we can have a lot of
> > pages in the swap cache that have already been swapped out, and are
> > waiting to be unmapped, uncharged, and freed, just like usual page
> > cache. Why do we use batching for file cache pages then?
> 
> The batching is mostly for munmap().  We do it for reclaim because
> it's convenient, but I don't think an extra word per struct page to
> batch one, sometimes a few, locked subtractions per swapped out page
> is a reasonable trade-off.
> 
> > > > Besides, it looks asymmetric with respect to the page cache uncharge
> > > > path, where we still defer uncharge to mem_cgroup_uncharge_list(), and I
> > > > personally rather dislike this asymmetry.
> > > 
> > > The asymmetry is inherent in the fact that we mave memory and
> > > memory+swap accounting, and here a memory charge is transferred out to
> > > swap.  Before, the asymmetry was in mem_cgroup_uncharge_list() where
> > > we separate out memory and memsw pages (which the next patch fixes).
> > 
> > I agree that memsw is inherently asymmetric, but IMO it isn't the case
> > for swap *cache* vs page *cache*. We handle them similarly - removing
> > from a mapping, uncharging, freeing. If one wants batching, why
> > shouldn't the other?
> 
> It has to be worth it in practical terms.  You can argue symmetry
> between swap cache and page cache, but swapping simply is a much
> colder path than reclaiming page cache.  Our reclaim algorithm avoids
> it like the plague.
> 
> > > So nothing changed, the ugliness was just moved around.  I actually
> > > like it better now that it's part of the swap controller, because
> > > that's where the nastiness actually comes from.  This will all go away
> > > when we account swap separately.  Then, swapped pages can keep their
> > > memory charge until mem_cgroup_uncharge() again and the swap charge
> > > will be completely independent from it.  This reshuffling is just
> > > necessary because it allows us to get rid of the per-page flag.
> > 
> > Do you mean that swap cache uncharge batching will be back soon?
> 
> Well, yes, once we switch from memsw to a separate swap couter, it
> comes automatically.  Pages no longer carry two charges, and so the
> uncharging of pages doesn't have to distinguish between swapped out
> pages and other pages anymore.

With this in mind,

Acked-by: Vladimir Davydov <vdavydov@parallels.com>

  reply	other threads:[~2014-10-22 15:37 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-20 15:22 [patch 0/4] mm: memcontrol: remove the page_cgroup->flags field Johannes Weiner
2014-10-20 15:22 ` Johannes Weiner
2014-10-20 15:22 ` [patch 1/4] mm: memcontrol: uncharge pages on swapout Johannes Weiner
2014-10-20 15:22   ` Johannes Weiner
2014-10-21  1:07   ` Kamezawa Hiroyuki
2014-10-21  1:07     ` Kamezawa Hiroyuki
2014-10-21 20:39     ` Johannes Weiner
2014-10-21 20:39       ` Johannes Weiner
2014-10-21 12:52   ` Vladimir Davydov
2014-10-21 12:52     ` Vladimir Davydov
2014-10-21 21:03     ` Johannes Weiner
2014-10-21 21:03       ` Johannes Weiner
2014-10-21 21:03       ` Johannes Weiner
2014-10-22  8:33       ` Vladimir Davydov
2014-10-22  8:33         ` Vladimir Davydov
2014-10-22  8:33         ` Vladimir Davydov
2014-10-22 13:20         ` Johannes Weiner
2014-10-22 13:20           ` Johannes Weiner
2014-10-22 15:37           ` Vladimir Davydov [this message]
2014-10-22 15:37             ` Vladimir Davydov
     [not found]   ` <1413818532-11042-2-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2014-10-22 15:34     ` Michal Hocko
2014-10-22 15:34       ` Michal Hocko
2014-10-22 15:34       ` Michal Hocko
2014-10-20 15:22 ` [patch 2/4] mm: memcontrol: remove unnecessary PCG_MEMSW memory+swap charge flag Johannes Weiner
2014-10-20 15:22   ` Johannes Weiner
2014-10-22  1:50   ` Kamezawa Hiroyuki
2014-10-22  1:50     ` Kamezawa Hiroyuki
2014-10-22  1:50     ` Kamezawa Hiroyuki
2014-10-22 15:43   ` Vladimir Davydov
2014-10-22 15:43     ` Vladimir Davydov
2014-10-22 15:46   ` Michal Hocko
2014-10-22 15:46     ` Michal Hocko
2014-10-20 15:22 ` [patch 3/4] mm: memcontrol: remove unnecessary PCG_MEM memory " Johannes Weiner
2014-10-20 15:22   ` Johannes Weiner
2014-10-22  1:52   ` Kamezawa Hiroyuki
2014-10-22  1:52     ` Kamezawa Hiroyuki
2014-10-22 15:44   ` Vladimir Davydov
2014-10-22 15:44     ` Vladimir Davydov
2014-10-22 15:49   ` Michal Hocko
2014-10-22 15:49     ` Michal Hocko
2014-10-20 15:22 ` [patch 4/4] mm: memcontrol: remove unnecessary PCG_USED pc->mem_cgroup valid flag Johannes Weiner
2014-10-20 15:22   ` Johannes Weiner
     [not found]   ` <1413818532-11042-5-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2014-10-22  1:54     ` Kamezawa Hiroyuki
2014-10-22  1:54       ` Kamezawa Hiroyuki
2014-10-22  1:54       ` Kamezawa Hiroyuki
2014-10-22 16:05   ` Vladimir Davydov
2014-10-22 16:05     ` Vladimir Davydov
2014-10-22 16:11   ` Michal Hocko
2014-10-22 16:11     ` Michal Hocko

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=20141022153725.GY16496@esperanza \
    --to=vdavydov@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    /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.