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


Groups > linux.kernel > #1480188

Re: [RFC PATCH 0/4] Reduce tree_lock contention during swap and reclaim of a single file v1

From Mel Gorman <mgorman@techsingularity.net>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 0/4] Reduce tree_lock contention during swap and reclaim of a single file v1
Date 2016-09-09 18:20 +0200
Message-ID <sfwGZ-5gP-23@gated-at.bofh.it> (permalink)
References <sfqLf-1c3-23@gated-at.bofh.it> <sfw4h-4M9-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Sep 09, 2016 at 08:31:27AM -0700, Linus Torvalds wrote:
> On Fri, Sep 9, 2016 at 2:59 AM, Mel Gorman <mgorman@techsingularity.net> wrote:
> >
> > The progression of this series has been unsatisfactory.
> 
> Yeah, I have to say that I particularly don't like patch #1.

There isn't many ways to make it prettier. Making it nicer is partially
hindered by the fact that tree_lock is IRQ-safe for IO completions but
even if that was addressed there might be lock ordering issues.

> It's some
> rather nasty complexity for dubious gains, and holding the lock for
> longer times might have downsides.
> 

Kswapd reclaim would delay a parallel truncation for example. Doubtful it
matters but the possibility is there.

The gain in swapping is nice but ramdisk is excessively artifical. It might
matter if someone reported it made a big difference swapping to faster
storage like SSD or NVMe although the cases where fast swap is important
are few -- overcommitted host with multiple idle VMs with a new active VM
starting is the only one that springs to mind.

> So I think this series is one of those "we need to find that it makes
> a big positive impact" to make sense.
> 

Agreed. I don't mind leaving it on the back burner unless Dave reports
it really helps or a new bug report about realistic tree_lock contention
shows up.

-- 
Mel Gorman
SUSE Labs

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH 0/4] Reduce tree_lock contention during swap and reclaim of a single file v1 Mel Gorman <mgorman@techsingularity.net> - 2016-09-09 12:00 +0200
  [PATCH 2/4] block, brd: Treat storage as non-rotational Mel Gorman <mgorman@techsingularity.net> - 2016-09-09 12:10 +0200
  [PATCH 3/4] mm, vmscan: Stall kswapd if contending on tree_lock Mel Gorman <mgorman@techsingularity.net> - 2016-09-09 12:10 +0200
  [PATCH 1/4] mm, vmscan: Batch removal of mappings under a single lock during reclaim Mel Gorman <mgorman@techsingularity.net> - 2016-09-09 12:10 +0200
    Re: [PATCH 1/4] mm, vmscan: Batch removal of mappings under a single  lock during reclaim Peter Zijlstra <peterz@infradead.org> - 2016-09-16 15:30 +0200
      Re: [PATCH 1/4] mm, vmscan: Batch removal of mappings under a single  lock during reclaim Peter Zijlstra <peterz@infradead.org> - 2016-09-16 16:10 +0200
      Re: [PATCH 1/4] mm, vmscan: Batch removal of mappings under a single  lock during reclaim Linus Torvalds <torvalds@linux-foundation.org> - 2016-09-16 20:40 +0200
        Re: [PATCH 1/4] mm, vmscan: Batch removal of mappings under a single  lock during reclaim Peter Zijlstra <peterz@infradead.org> - 2016-09-17 03:40 +0200
  [PATCH 4/4] mm, vmscan: Potentially stall direct reclaimers on tree_lock contention Mel Gorman <mgorman@techsingularity.net> - 2016-09-09 12:10 +0200
  Re: [RFC PATCH 0/4] Reduce tree_lock contention during swap and  reclaim of a single file v1 Linus Torvalds <torvalds@linux-foundation.org> - 2016-09-09 17:40 +0200
    Re: [RFC PATCH 0/4] Reduce tree_lock contention during swap and  reclaim of a single file v1 Mel Gorman <mgorman@techsingularity.net> - 2016-09-09 18:20 +0200
      Re: [RFC PATCH 0/4] Reduce tree_lock contention during swap and reclaim of a single file v1 "Huang\, Ying" <ying.huang@intel.com> - 2016-09-09 20:20 +0200

csiph-web