From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, Eryu Guan <eguan@redhat.com>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/4] ext4: Fix deadlock during page writeback
Date: Mon, 4 Jul 2016 23:38:24 -0400 [thread overview]
Message-ID: <20160705033824.GD15193@thunk.org> (raw)
In-Reply-To: <20160704155107.GB12022@quack2.suse.cz>
On Mon, Jul 04, 2016 at 05:51:07PM +0200, Jan Kara wrote:
> On Mon 04-07-16 10:14:35, Ted Tso wrote:
> > This is what I'm currently testing; do you have objections to this?
>
> Meh, I don't like it but it should work... Did you see any improvement with
> your change or are you just operating on the assumption that you want as
> few code while the handle is running as possible?
I haven't had a chance to try to benchmark it yet. I've working at
home over the long (US) holiday weekend, and the high core-count
servers I need are on the internal work network, and it's pain to
access them from home.
I've just been tired of seeing the sort of analysis that can be found
at papers like:
https://www.usenix.org/system/files/conference/fast14/fast14-paper_kang.pdf
(And there's a ATC 2016 paper which shows that things haven't gotten
any better as well.)
Given that our massive lock bottlenecks come from the j_list_lock and
j_state_lock, and that most of the contention happens when we are
closing down a transaction for a commit, there is a pretty direct
correlation between handle lifetimes and the contention statistics on
the journal spinlocks. Enough so that I've instrumented the handle
type and handle line number in the jbd2_handle_stats tracepoint, and
work to push down on the handle hold times have definitely helped our
contention numbers.
So I do have experimental evidence that reducing code while the handle
is running does matter in general. I just don't have it for this
specific case yet....
Cheers,
- Ted
next prev parent reply other threads:[~2016-07-05 3:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 10:42 [PATCH 0/4] ext4: Fix deadlock during page writeback Jan Kara
2016-06-16 10:42 ` [PATCH 1/4] " Jan Kara
2016-06-30 15:05 ` Theodore Ts'o
2016-07-01 9:09 ` Jan Kara
2016-07-01 16:53 ` Theodore Ts'o
2016-07-01 17:40 ` Jan Kara
2016-07-01 21:26 ` Theodore Ts'o
2016-07-04 14:00 ` Jan Kara
2016-07-04 15:20 ` Theodore Ts'o
2016-07-04 15:47 ` Jan Kara
2016-07-05 2:43 ` Theodore Ts'o
2016-07-06 7:04 ` Jan Kara
2016-07-04 14:14 ` Theodore Ts'o
2016-07-04 15:51 ` Jan Kara
2016-07-05 3:38 ` Theodore Ts'o [this message]
2016-07-06 7:51 ` Jan Kara
2016-07-06 12:35 ` Theodore Ts'o
2016-07-06 12:52 ` Jan Kara
2016-07-06 14:27 ` Theodore Ts'o
2016-07-06 14:41 ` Jan Kara
2016-06-16 10:42 ` [PATCH 2/4] jbd2: Move lockdep instrumentation for jbd2 handles Jan Kara
2016-06-30 15:34 ` Theodore Ts'o
2016-06-16 10:42 ` [PATCH 3/4] jbd2: Move lockdep tracking to journal_s Jan Kara
2016-06-16 11:42 ` kbuild test robot
2016-06-30 15:40 ` Theodore Ts'o
2016-06-16 10:42 ` [PATCH 4/4] jbd2: Track more dependencies on transaction commit Jan Kara
2016-06-30 15:45 ` Theodore Ts'o
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=20160705033824.GD15193@thunk.org \
--to=tytso@mit.edu \
--cc=eguan@redhat.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=stable@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).