From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754379AbcEDRNV (ORCPT ); Wed, 4 May 2016 13:13:21 -0400 Received: from mga03.intel.com ([134.134.136.65]:47411 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751040AbcEDRNT (ORCPT ); Wed, 4 May 2016 13:13:19 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,578,1455004800"; d="scan'208";a="968720493" Message-ID: <1462381986.30611.28.camel@linux.intel.com> Subject: Re: [PATCH 0/7] mm: Improve swap path scalability with batched operations From: Tim Chen To: Michal Hocko Cc: Andrew Morton , Vladimir Davydov , Johannes Weiner , Minchan Kim , Hugh Dickins , "Kirill A.Shutemov" , Andi Kleen , Aaron Lu , Huang Ying , linux-mm , linux-kernel@vger.kernel.org Date: Wed, 04 May 2016 10:13:06 -0700 In-Reply-To: <20160504124535.GJ29978@dhcp22.suse.cz> References: <1462309239.21143.6.camel@linux.intel.com> <20160504124535.GJ29978@dhcp22.suse.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2016-05-04 at 14:45 +0200, Michal Hocko wrote: > On Tue 03-05-16 14:00:39, Tim Chen wrote: > [...] > > > >  include/linux/swap.h |  29 ++- > >  mm/swap_state.c      | 253 +++++++++++++----- > >  mm/swapfile.c        | 215 +++++++++++++-- > >  mm/vmscan.c          | 725 ++++++++++++++++++++++++++++++++++++++- > > ------------ > >  4 files changed, 945 insertions(+), 277 deletions(-) > This is rather large change for a normally rare path. We have been > trying to preserve the anonymous memory as much as possible and > rather > push the page cache out. In fact swappiness is ignored most of the > time for the vast majority of workloads. > > So this would help anonymous mostly workloads and I am really > wondering > whether this is something worth bothering without further and deeper > rethinking of our current reclaim strategy. I fully realize that the > swap out sucks and that the new storage technologies might change the > way how we think about anonymous memory being so "special" wrt. disk > based caches but I would like to see a stronger use case than "we > have > been playing with some artificial use case and it scales better" With non-volatile ram based block devices, swap device could be very fast, approaching RAM speed and can potentially be used as a secondary memory. Just configuring these NVRAM as swap will be an easy way for apps to make use of them without doing any heavy lifting to change the apps.  But the swap path is so  un-scalable today that such use case is unfeasible, even more so for multi-threaded server machines. I understand that the patch set is a little large. Any better ideas for achieving similar ends will be appreciated.  I put out these patches in the hope that it will spur solutions to improve swap. Perhaps the first two patches to make shrink_page_list into smaller components can be considered first, as a first step  to make any changes to the reclaim code easier. Thanks. Tim