From: "Huang\, Ying" <ying.huang@intel.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
"Dave Chinner" <david@fromorbit.com>,
Ying Huang <ying.huang@intel.com>,
"Michal Hocko" <mhocko@kernel.org>,
"Tim C. Chen" <tim.c.chen@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Andi Kleen <andi.kleen@intel.com>
Subject: Re: [RFC PATCH 0/4] Reduce tree_lock contention during swap and reclaim of a single file v1
Date: Fri, 09 Sep 2016 11:16:35 -0700 [thread overview]
Message-ID: <8760q52b24.fsf@yhuang-mobile.sh.intel.com> (raw)
In-Reply-To: <20160909161908.GG8119@techsingularity.net> (Mel Gorman's message of "Fri, 9 Sep 2016 17:19:08 +0100")
Mel Gorman <mgorman@techsingularity.net> writes:
> 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.
I will try to provide some data for the NVMe disk. I think the trend is
that the performance of the disk is increasing fast and will continue in
the near future at least. We found we cannot saturate the latest NVMe
disk when swapping because of locking issues in swap and page reclaim
path.
The swap usage problem could be a "Chicken and Egg" problem. Because
swap performance is poor, nobody uses swap, and because nobody uses
swap, nobody works on improving the performance of the swap. With the
faster and faster storage device, swap could be more popular in the
future if we optimize its performance to catch up with the performance
of the storage.
>> 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.
Best Regards,
Huang, Ying
prev parent reply other threads:[~2016-09-09 18:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 9:59 Mel Gorman
2016-09-09 9:59 ` [PATCH 1/4] mm, vmscan: Batch removal of mappings under a single lock during reclaim Mel Gorman
2016-09-16 13:25 ` Peter Zijlstra
2016-09-16 14:07 ` Peter Zijlstra
2016-09-16 18:33 ` Linus Torvalds
2016-09-17 1:36 ` Peter Zijlstra
2016-09-09 9:59 ` [PATCH 2/4] block, brd: Treat storage as non-rotational Mel Gorman
2016-09-09 9:59 ` [PATCH 3/4] mm, vmscan: Stall kswapd if contending on tree_lock Mel Gorman
2016-09-09 9:59 ` [PATCH 4/4] mm, vmscan: Potentially stall direct reclaimers on tree_lock contention Mel Gorman
2016-09-09 15:31 ` [RFC PATCH 0/4] Reduce tree_lock contention during swap and reclaim of a single file v1 Linus Torvalds
2016-09-09 16:19 ` Mel Gorman
2016-09-09 18:16 ` Huang, Ying [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8760q52b24.fsf@yhuang-mobile.sh.intel.com \
--to=ying.huang@intel.com \
--cc=andi.kleen@intel.com \
--cc=dave.hansen@intel.com \
--cc=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=tim.c.chen@intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®