Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1393816 > unrolled thread

[PATCH 0/7] mm: Improve swap path scalability with batched operations

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 0/7] mm: Improve swap path scalability with batched  operations Tim Chen <tim.c.chen@linux.intel.com> - 2016-05-03 23:10 +0200
    Re: [PATCH 0/7] mm: Improve swap path scalability with batched  operations Michal Hocko <mhocko@kernel.org> - 2016-05-04 14:50 +0200
      Re: [PATCH 0/7] mm: Improve swap path scalability with batched  operations Tim Chen <tim.c.chen@linux.intel.com> - 2016-05-04 19:20 +0200
        Re: [PATCH 0/7] mm: Improve swap path scalability with batched  operations Michal Hocko <mhocko@kernel.org> - 2016-05-04 21:50 +0200
          Re: [PATCH 0/7] mm: Improve swap path scalability with batched  operations Andi Kleen <andi@firstfloor.org> - 2016-05-04 23:10 +0200
          Re: [PATCH 0/7] mm: Improve swap path scalability with batched  operations Johannes Weiner <hannes@cmpxchg.org> - 2016-05-04 23:30 +0200
            Re: [PATCH 0/7] mm: Improve swap path scalability with batched  operations Minchan Kim <minchan@kernel.org> - 2016-05-05 02:10 +0200
            Re: [PATCH 0/7] mm: Improve swap path scalability with batched  operations Michal Hocko <mhocko@kernel.org> - 2016-05-05 09:50 +0200
              Re: [PATCH 0/7] mm: Improve swap path scalability with batched  operations Tim Chen <tim.c.chen@linux.intel.com> - 2016-05-05 18:00 +0200

#1393816 — [PATCH 0/7] mm: Improve swap path scalability with batched operations

The page swap out path is not scalable due to the numerous locks
acquired and released along the way, which are all executed on a page
by page basis, e.g.:

1. The acquisition of the mapping tree lock in swap cache when adding
a page to swap cache, and then again when deleting a page from swap cache after
it has been swapped out. 
2. The acquisition of the lock on swap device to allocate a swap slot for
a page to be swapped out. 

With the advent of high speed block devices that's several orders  
of magnitude faster than the old spinning disks, these bottlenecks
become fairly significant, especially on server class machines
with many theads running.  To reduce these locking costs, this patch
series attempt to batch the pages on the following oprations needed
on for swap:
1. Allocate swap slots in large batches, so locks on the swap device
don't need to be acquired as often. 
2. Add anonymous pages to the swap cache for the same swap device in             
batches, so the mapping tree lock can be acquired less.
3. Delete pages from swap cache also in batches.

We experimented the effect of this patches. We set up N threads to access
memory in excess of memory capcity, causing swap.  In experiments using
a single pmem based fast block device on a 2 socket machine, we saw
that for 1 thread, there is a ~25% increase in swap throughput and for
16 threads, the swap throughput increase by ~85%, when compared with the
vanilla kernel. Batching helps even for 1 thread because of contention
with kswapd when doing direct memory reclaim.

Feedbacks and reviews to this patch series are much appreciated.

Thanks.

Tim


Tim Chen (7):
  mm: Cleanup - Reorganize the shrink_page_list code into smaller
    functions
  mm: Group the processing of anonymous pages to be swapped in
    shrink_page_list
  mm: Add new functions to allocate swap slots in batches
  mm: Shrink page list batch allocates swap slots for page swapping
  mm: Batch addtion of pages to swap cache
  mm: Cleanup - Reorganize code to group handling of page
  mm: Batch unmapping of pages that are in swap cache

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

-- 
2.5.5

[toc] | [next] | [standalone]

#1394258

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"
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1394560

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

[toc] | [prev] | [next] | [standalone]

#1394674

On Wed 04-05-16 10:13:06, Tim Chen wrote:
> 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.

In order this to work other quite intrusive changes to the current
reclaim decisions would have to be made though. This is what I tried to
say. Look at get_scan_count() on how we are making many steps to ignore
swappiness or prefer the page cache. Even when we make swapout scale it
won't help much if we do not swap out that often. That's why I claim
that we really should think more long term and maybe reconsider these
decisions which were based on the rotating rust for the swap devices.

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

I didn't get to review those yet and probably will not get to them
shortly (sorry about that). shrink_page_list is surely one giant
function that is calling for a better layout/split out. I wouldn't be
opposed but there are some subtle details lurking there which make
clean ups non-trivial. I will not discourage you from trying to get it
into shape of course.

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1394718

> In order this to work other quite intrusive changes to the current
> reclaim decisions would have to be made though. This is what I tried to
> say. Look at get_scan_count() on how we are making many steps to ignore
> swappiness or prefer the page cache. Even when we make swapout scale it
> won't help much if we do not swap out that often. That's why I claim

But if you made swapout to scale you would need some equivalent
of Tim's patches for the swap path... So you need them in case.

> that we really should think more long term and maybe reconsider these
> decisions which were based on the rotating rust for the swap devices.

Sure that makes sense, but why not start with low hanging fruit
in basic performance, like Tim did? Usually that is how Linux
changes work, steady evolution, not revolution.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

[toc] | [prev] | [next] | [standalone]

#1394728

On Wed, May 04, 2016 at 09:49:02PM +0200, Michal Hocko wrote:
> On Wed 04-05-16 10:13:06, Tim Chen wrote:
> In order this to work other quite intrusive changes to the current
> reclaim decisions would have to be made though. This is what I tried to
> say. Look at get_scan_count() on how we are making many steps to ignore
> swappiness or prefer the page cache. Even when we make swapout scale it
> won't help much if we do not swap out that often. That's why I claim
> that we really should think more long term and maybe reconsider these
> decisions which were based on the rotating rust for the swap devices.

While I agree that such balancing rework is necessary to make swap
perform optimally, I don't see why this would be a dependency for
making the mechanical swapout paths a lot leaner.

I'm actually working on improving the LRU balancing decisions for fast
random IO swap devices, and hope to have something to submit soon.

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

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.

I realize this is fairly vague feedback; I'll try to take a closer
look at the patches. But I do think this work is going in the right
direction and there is plenty of justification for making these paths
more efficient.

[toc] | [prev] | [next] | [standalone]

#1394802

On Wed, May 04, 2016 at 05:25:06PM -0400, Johannes Weiner wrote:
> On Wed, May 04, 2016 at 09:49:02PM +0200, Michal Hocko wrote:
> > On Wed 04-05-16 10:13:06, Tim Chen wrote:
> > In order this to work other quite intrusive changes to the current
> > reclaim decisions would have to be made though. This is what I tried to
> > say. Look at get_scan_count() on how we are making many steps to ignore
> > swappiness or prefer the page cache. Even when we make swapout scale it
> > won't help much if we do not swap out that often. That's why I claim
> > that we really should think more long term and maybe reconsider these
> > decisions which were based on the rotating rust for the swap devices.
> 
> While I agree that such balancing rework is necessary to make swap
> perform optimally, I don't see why this would be a dependency for
> making the mechanical swapout paths a lot leaner.

I agree.

> 
> I'm actually working on improving the LRU balancing decisions for fast
> random IO swap devices, and hope to have something to submit soon.

Good to hear! I really have an interest about that because we already
have used such fast random IO swap device. zRAM although I'm not
sure it's really fast as much as such NVRAM. Anyway, it would be very
benefit for zram.

> 
> > > 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.
> 
> 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.
> 
> I realize this is fairly vague feedback; I'll try to take a closer
> look at the patches. But I do think this work is going in the right
> direction and there is plenty of justification for making these paths
> more efficient.

+1

[toc] | [prev] | [next] | [standalone]

#1394912

On Wed 04-05-16 17:25:06, Johannes Weiner wrote:
> On Wed, May 04, 2016 at 09:49:02PM +0200, Michal Hocko wrote:
> > On Wed 04-05-16 10:13:06, Tim Chen wrote:
> > In order this to work other quite intrusive changes to the current
> > reclaim decisions would have to be made though. This is what I tried to
> > say. Look at get_scan_count() on how we are making many steps to ignore
> > swappiness or prefer the page cache. Even when we make swapout scale it
> > won't help much if we do not swap out that often. That's why I claim
> > that we really should think more long term and maybe reconsider these
> > decisions which were based on the rotating rust for the swap devices.
> 
> While I agree that such balancing rework is necessary to make swap
> perform optimally, I don't see why this would be a dependency for
> making the mechanical swapout paths a lot leaner.

Ohh, I didn't say this would be a dependency. I am all for preparing
the code for a better scaling I just felt that the patch is quite large
with a small benefit at this moment and the initial description was not
very clear about the motivation and changes seemed to be shaped by an
artificial test case.

> I'm actually working on improving the LRU balancing decisions for fast
> random IO swap devices, and hope to have something to submit soon.

That is really good to hear!

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

Agreed!

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1395199

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web