From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-wm0-f69.google.com (mail-wm0-f69.google.com [74.125.82.69])
	by kanga.kvack.org (Postfix) with ESMTP id 8D8766B0069
	for <linux-mm@kvack.org>; Wed, 28 Dec 2016 09:57:37 -0500 (EST)
Received: by mail-wm0-f69.google.com with SMTP id k184so21321720wme.4
        for <linux-mm@kvack.org>; Wed, 28 Dec 2016 06:57:37 -0800 (PST)
Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15])
        by mx.google.com with ESMTPS id 74si50591656wmh.144.2016.12.28.06.57.35
        for <linux-mm@kvack.org>
        (version=TLS1 cipher=AES128-SHA bits=128/128);
        Wed, 28 Dec 2016 06:57:36 -0800 (PST)
Date: Wed, 28 Dec 2016 15:57:32 +0100
From: Michal Hocko <mhocko@kernel.org>
Subject: [LSF/MM TOPIC] plans for future swap changes
Message-ID: <20161228145732.GE11470@dhcp22.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>, Tim Chen <tim.c.chen@linux.intel.com>

This is something I would be interested to discuss even though I am not
working on it directly. Sorry if I hijacked the topic from those who
planned to post them.

It seems that the time to reconsider our approach to the swap storage is
come already and there are multiple areas to discuss. I would be
interested at least in the following
1) anon/file balancing. Johannes has posted some work already and I am
   really interested in the future plans for it.
2) swap trashing detection is something that we are lacking for a long
   time and it would be great if we could do something to help
   situations when the machine is effectively out of memory but still
   hopelessly trying to swap in and out few pages while the machine is
   basically unusable. I hope that 1) will give us some bases but I am
   not sure how much we will need on top.
3) optimizations for the swap out paths - Tim Chen and other guys from
   Intel are already working on this. I didn't get time to review this
   closely - mostly because I am not closely familiar with the swapout
   code and it takes quite some time to get into all subtle details.
   I mainly interested in what are the plans in this area and how they
   should be coordinated with other swap related changes
4) Do we want the native THP swap in/out support?

Other plans?
-- 
Michal Hocko
SUSE Labs

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72])
	by kanga.kvack.org (Postfix) with ESMTP id 5E2916B0038
	for <linux-mm@kvack.org>; Wed,  4 Jan 2017 01:40:37 -0500 (EST)
Received: by mail-wm0-f72.google.com with SMTP id w13so82314117wmw.0
        for <linux-mm@kvack.org>; Tue, 03 Jan 2017 22:40:37 -0800 (PST)
Received: from gum.cmpxchg.org (gum.cmpxchg.org. [85.214.110.215])
        by mx.google.com with ESMTPS id kk10si80331669wjc.3.2017.01.03.22.40.35
        for <linux-mm@kvack.org>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 03 Jan 2017 22:40:35 -0800 (PST)
Date: Wed, 4 Jan 2017 01:40:24 -0500
From: Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [LSF/MM TOPIC] plans for future swap changes
Message-ID: <20170104064024.GA3676@cmpxchg.org>
References: <20161228145732.GE11470@dhcp22.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161228145732.GE11470@dhcp22.suse.cz>
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, Tim Chen <tim.c.chen@linux.intel.com>, Shaohua Li <shli@fb.com>

Hi,

On Wed, Dec 28, 2016 at 03:57:32PM +0100, Michal Hocko wrote:
> This is something I would be interested to discuss even though I am not
> working on it directly. Sorry if I hijacked the topic from those who
> planned to post them.
> 
> It seems that the time to reconsider our approach to the swap storage is
> come already and there are multiple areas to discuss. I would be
> interested at least in the following
> 1) anon/file balancing. Johannes has posted some work already and I am
>    really interested in the future plans for it.

They needed some surgery to work on top of the node-LRU rewrite. I've
restored performance on the benchmarks I was using and will post them
after some more cleaning up and writing changelogs for the new pieces.

> 2) swap trashing detection is something that we are lacking for a long
>    time and it would be great if we could do something to help
>    situations when the machine is effectively out of memory but still
>    hopelessly trying to swap in and out few pages while the machine is
>    basically unusable. I hope that 1) will give us some bases but I am
>    not sure how much we will need on top.

Yes, this keeps biting us quite frequently. Not with swap so much as
page cache, but it's the same problem: while we know all the thrashing
*events*, we don't know how much they truly cost us. I've started
drafting a thrashing quantification patch based on feedback from the
Kernel Summit, attaching it below. It's unbelievably crude and needs
more thought on sampling/decaying, as well as on filtering out swapins
that happen after pressure has otherwise subsided. But it does give me
a reasonable-looking thrashing ratio under memory pressure.

> 3) optimizations for the swap out paths - Tim Chen and other guys from
>    Intel are already working on this. I didn't get time to review this
>    closely - mostly because I am not closely familiar with the swapout
>    code and it takes quite some time to get into all subtle details.
>    I mainly interested in what are the plans in this area and how they
>    should be coordinated with other swap related changes
> 4) Do we want the native THP swap in/out support?

Shaohua had some opinions on this, he might be interested in joining
this discussion. CCing him.

---

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70])
	by kanga.kvack.org (Postfix) with ESMTP id 6E84E6B0038
	for <linux-mm@kvack.org>; Wed,  4 Jan 2017 12:16:19 -0500 (EST)
Received: by mail-pg0-f70.google.com with SMTP id f188so1595939531pgc.1
        for <linux-mm@kvack.org>; Wed, 04 Jan 2017 09:16:19 -0800 (PST)
Received: from mga03.intel.com (mga03.intel.com. [134.134.136.65])
        by mx.google.com with ESMTPS id b1si73094157pld.129.2017.01.04.09.16.18
        for <linux-mm@kvack.org>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 04 Jan 2017 09:16:18 -0800 (PST)
Message-ID: <1483550177.3064.104.camel@linux.intel.com>
Subject: Re: [LSF/MM TOPIC] plans for future swap changes
From: Tim Chen <tim.c.chen@linux.intel.com>
Date: Wed, 04 Jan 2017 09:16:17 -0800
In-Reply-To: <20170104064024.GA3676@cmpxchg.org>
References: <20161228145732.GE11470@dhcp22.suse.cz>
	 <20170104064024.GA3676@cmpxchg.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@kernel.org>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, Shaohua Li <shli@fb.com>


> 
> > 
> > 3) optimizations for the swap out paths - Tim Chen and other guys from
> > A A A Intel are already working on this. I didn't get time to review this
> > A A A closely - mostly because I am not closely familiar with the swapout
> > A A A code and it takes quite some time to get into all subtle details.
> > A A A I mainly interested in what are the plans in this area and how they
> > A A A should be coordinated with other swap related changes

We are also planning on discussing this topic at the mm summit, if the
patch series have not yet got into mainline, plus a couple
of others swap related stuff. A I'll be sending out our proposal separately.

Tim

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70])
	by kanga.kvack.org (Postfix) with ESMTP id 567F06B0253
	for <linux-mm@kvack.org>; Wed,  4 Jan 2017 13:13:49 -0500 (EST)
Received: by mail-pg0-f70.google.com with SMTP id f188so1599324962pgc.1
        for <linux-mm@kvack.org>; Wed, 04 Jan 2017 10:13:49 -0800 (PST)
Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com. [67.231.153.30])
        by mx.google.com with ESMTPS id v15si206456plk.21.2017.01.04.10.13.48
        for <linux-mm@kvack.org>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 04 Jan 2017 10:13:48 -0800 (PST)
Date: Wed, 4 Jan 2017 10:13:27 -0800
From: Shaohua Li <shli@fb.com>
Subject: Re: [LSF/MM TOPIC] plans for future swap changes
Message-ID: <20170104181221.GA73049@shli-mbp.local>
References: <20161228145732.GE11470@dhcp22.suse.cz>
 <20170104064024.GA3676@cmpxchg.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170104064024.GA3676@cmpxchg.org>
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, Tim Chen <tim.c.chen@linux.intel.com>

On Wed, Jan 04, 2017 at 01:40:24AM -0500, Johannes Weiner wrote:
> Hi,
> 
> On Wed, Dec 28, 2016 at 03:57:32PM +0100, Michal Hocko wrote:
> > This is something I would be interested to discuss even though I am not
> > working on it directly. Sorry if I hijacked the topic from those who
> > planned to post them.
> > 
> > It seems that the time to reconsider our approach to the swap storage is
> > come already and there are multiple areas to discuss. I would be
> > interested at least in the following
> > 1) anon/file balancing. Johannes has posted some work already and I am
> >    really interested in the future plans for it.
> 
> They needed some surgery to work on top of the node-LRU rewrite. I've
> restored performance on the benchmarks I was using and will post them
> after some more cleaning up and writing changelogs for the new pieces.
> 
> > 2) swap trashing detection is something that we are lacking for a long
> >    time and it would be great if we could do something to help
> >    situations when the machine is effectively out of memory but still
> >    hopelessly trying to swap in and out few pages while the machine is
> >    basically unusable. I hope that 1) will give us some bases but I am
> >    not sure how much we will need on top.
> 
> Yes, this keeps biting us quite frequently. Not with swap so much as
> page cache, but it's the same problem: while we know all the thrashing
> *events*, we don't know how much they truly cost us. I've started
> drafting a thrashing quantification patch based on feedback from the
> Kernel Summit, attaching it below. It's unbelievably crude and needs
> more thought on sampling/decaying, as well as on filtering out swapins
> that happen after pressure has otherwise subsided. But it does give me
> a reasonable-looking thrashing ratio under memory pressure.
> 
> > 3) optimizations for the swap out paths - Tim Chen and other guys from
> >    Intel are already working on this. I didn't get time to review this
> >    closely - mostly because I am not closely familiar with the swapout
> >    code and it takes quite some time to get into all subtle details.
> >    I mainly interested in what are the plans in this area and how they
> >    should be coordinated with other swap related changes
> > 4) Do we want the native THP swap in/out support?
> 
> Shaohua had some opinions on this, he might be interested in joining
> this discussion. CCing him.

Sure, I'm very interested in the topic. I'm pretty interested in reducing swap
latency and making the latency more predictable. I had some random ideas and
did some experiments before (no real patch though, sorry), like io poll for
swapin, reduce reclaim batch count in direct page reclaim, and a flush-like
proactive swapout and so on.

Thanks,
Shaohua

--
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>