linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Ted Tso <tytso@mit.edu>
Cc: <linux-ext4@vger.kernel.org>, Jan Kara <jack@suse.cz>
Subject: [PATCH 0/2 v2] jbd2: Fix leaked transaction credits
Date: Wed, 20 May 2020 15:31:17 +0200	[thread overview]
Message-ID: <20200520133119.1383-1-jack@suse.cz> (raw)

Hello,

after debugging more the reason why fsmark run is slower in dioread_nolock
mode (which became the default in 5.6), I've found jbd2 actually leaks
reserved credits if we start a transaction with reserved handle and then don't
use it. The first patch in the series is a small (and independent) cleanup in
the area, the second patch fixes the leak.

Then there was another revelation for me that in this workload ext4 actually
starts lots of reserved transaction handles that are unused. This is due to the
way how ext4 writepages code works - it starts a transaction, then inspects
page cache and writes one extent if found. Then starts again a transaction and
checks whether there's more to write. So for single extent files we always
start transaction twice, second time only to find there's nothing more to
write. In case all blocks are already allocated, we wouldn't even have to start
transaction at all.  This probably also deserves to be fixed but a simple fix I
made seems to break page writeback so I need to dig more into it and I want to
push out the obvious jbd2 fix early.

Changes since v1:
* Add reviewed-by tag
* Fixed up one coding style issue pointed out by Andreas

								Honza

             reply	other threads:[~2020-05-20 13:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 13:31 Jan Kara [this message]
2020-05-20 13:31 ` [PATCH 1/2] ext4: Drop ext4_journal_free_reserved() Jan Kara
2020-05-20 19:29   ` Andreas Dilger
2020-05-29  2:43     ` Theodore Y. Ts'o
2020-05-20 13:31 ` [PATCH 2/2] jbd2: Avoid leaking transaction credits when unreserving handle Jan Kara
2020-05-29  2:44   ` Theodore Y. 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=20200520133119.1383-1-jack@suse.cz \
    --to=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).