[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180627231839.e5ac2f38e0397979d3db7765@linux-foundation.org>
Date: Wed, 27 Jun 2018 23:18:39 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Huang\, Ying" <ying.huang@...el.com>
Cc: <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
Hugh Dickins <hughd@...gle.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one
piece
On Thu, 28 Jun 2018 13:35:15 +0800 "Huang\, Ying" <ying.huang@...el.com> wrote:
> Andrew Morton <akpm@...ux-foundation.org> writes:
>
> > On Thu, 28 Jun 2018 13:29:09 +0800 "Huang\, Ying" <ying.huang@...el.com> wrote:
> >
> >> Andrew Morton <akpm@...ux-foundation.org> writes:
> >>
> >> > On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" <ying.huang@...el.com> wrote:
> >> >
> >> >> This is the final step of THP (Transparent Huge Page) swap
> >> >> optimization. After the first and second step, the splitting huge
> >> >> page is delayed from almost the first step of swapout to after swapout
> >> >> has been finished. In this step, we avoid splitting THP for swapout
> >> >> and swapout/swapin the THP in one piece.
> >> >
> >> > It's a tremendously good performance improvement. It's also a
> >> > tremendously large patchset :(
> >> >
> >> > And it depends upon your
> >> > mm-swap-fix-race-between-swapoff-and-some-swap-operations.patch and
> >> > mm-fix-race-between-swapoff-and-mincore.patch, the first of which has
> >> > been floating about since February without adequate review.
> >> >
> >> > I'll give this patchset a spin in -mm to see what happens and will come
> >> > back later to take a closer look. But the best I can do at this time
> >> > is to hopefully cc some possible reviewers :)
> >>
> >> Thanks a lot for your help! Hope more people can review it!
> >
> > I took it out of -mm again, temporarily. Due to a huge tangle with the
> > xarray conversions in linux-next.
>
> No problem. I will rebase the patchset on your latest -mm tree, or the
> next version to be released?
We need to figure that out with Matthew.
Probably the xarray conversions are simpler and more mature so yes,
probably they should be staged first.
Powered by blists - more mailing lists