linux-kernel - Re: [PATCH 0/7] mm: Improve swap path scalability with batched operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 05 May 2016 08:56:10 -0700
From:	Tim Chen <tim.c.chen@...ux.intel.com>
To:	Michal Hocko <mhocko@...nel.org>,
	Johannes Weiner <hannes@...xchg.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Vladimir Davydov <vdavydov@...tuozzo.com>,
	Minchan Kim <minchan@...nel.org>,
	Hugh Dickins <hughd@...gle.com>,
	"Kirill A.Shutemov" <kirill.shutemov@...ux.intel.com>,
	Andi Kleen <andi@...stfloor.org>,
	Aaron Lu <aaron.lu@...el.com>,
	Huang Ying <ying.huang@...el.com>,
	linux-mm <linux-mm@...ck.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] mm: Improve swap path scalability with batched
 operations

On Thu, 2016-05-05 at 09:49 +0200, Michal Hocko wrote:
> On Wed 04-05-16 17:25:06, Johannes Weiner wrote:
> > 
> > 
> 
> > 
> > > 
> > > > 
> > > > 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.
> > It makes sense that we need to batch swap allocation and swap cache
> > operations. Unfortunately, the patches as they stand turn
> > shrink_page_list() into an unreadable mess. This would need better
> > refactoring before considering them for upstream merging. The swap
> > allocation batching should not obfuscate the main sequence of
> > events
> > that is happening for both file-backed and anonymous pages.
> That was my first impression as well but to be fair I only skimmed
> through the patch so I might be just biased by the size.
> 
> > 
> > It'd also be great if the remove_mapping() batching could be done
> > universally for all pages, given that in many cases file pages from
> > the same inode also cluster together on the LRU.
> 

Agree.  I didn't try to do something on file mapped pages yet as
the changes in this patch set is already quite substantial.
But once we have some agreement on the batching on the anonymous
pages, the file backed pages could be grouped similarly.

Tim