linux-mm.kvack.org archive mirror
 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>

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

Thread overview: 22+ 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 ` [patch 1/4] mm: memcontrol: uncharge pages on swapout Johannes Weiner
2014-10-21  1:07   ` Kamezawa Hiroyuki
2014-10-21 20:39     ` Johannes Weiner
2014-10-21 12:52   ` Vladimir Davydov
2014-10-21 21:03     ` Johannes Weiner
2014-10-22  8:33       ` Vladimir Davydov
2014-10-22 13:20         ` Johannes Weiner
2014-10-22 15:37           ` Vladimir Davydov [this message]
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-22  1:50   ` Kamezawa Hiroyuki
2014-10-22 15:43   ` Vladimir Davydov
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-22  1:52   ` Kamezawa Hiroyuki
2014-10-22 15:44   ` Vladimir Davydov
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-22  1:54   ` Kamezawa Hiroyuki
2014-10-22 16:05   ` Vladimir Davydov
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 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).