From: Theodore Ts'o <tytso@mit.edu>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: linux-ext4@vger.kernel.org, linux-rt-users@vger.kernel.org
Subject: Re: [PATCH 2/4] jbd2/log_wait_for_space: drop checkpoint mutex when waiting
Date: Tue, 11 Jun 2013 09:03:33 -0400 [thread overview]
Message-ID: <20130611130333.GD23966@thunk.org> (raw)
In-Reply-To: <CAP=VYLofXDGQ5Vjc9S-p1VyVmzYU1ZxcZn5=mDtLZZbtdv9Lig@mail.gmail.com>
On Mon, Jun 10, 2013 at 11:20:50PM -0400, Paul Gortmaker wrote:
>
> Absolutely; will do that tomorrow and re-test on 3.10-rc5.
Thanks!! And by the way, I did look at patches #3 and #4 in your
series, and they looked fine. If you're going to be resending a new
patch series shortly, I won't bother grabbing them now and wait for
your new series, but if you won't have time to complete your testing,
the patches are independent and easy to validate by inspection, so I
could also just pull them into the ext4 tree earlier.
Cheers, and good luck figuring out the RT problem.
- Ted
P.S. About the bit spinlock patches in the RT Tree... Something that
might be interesting to do if you have the time is to measure the
performance differential on non-realtime kernels to replace the bit
spinlocks with normal spinlocks. The two main issues with it I can
forsee is the potential increased memory overhead (since a system can
have a huge number of bh's), but if this were offset with performance
gains (and we can confirm no performance losses moving away from bit
spinlocks), I'm not wedded to keeping them. Other folks in the
fsdevel community may push back on adding spinlocks to the bh that
many other file systems would have no use for, and that may very well
be a concern, but if we understand what the tradeoffs are, both pro
and con, it's something we can have a reasonable discussion about.
next prev parent reply other threads:[~2013-06-11 13:03 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-10 19:31 [RFC PATCH 0/4] ext4/jbd2: several possible mainline fixes Paul Gortmaker
2013-06-10 19:32 ` [PATCH 1/4] jbd2/journal_commit_transaction: relocate state lock to incorporate all users Paul Gortmaker
2013-06-11 2:12 ` Theodore Ts'o
2013-06-11 2:45 ` Paul Gortmaker
2013-06-11 2:52 ` Theodore Ts'o
2013-06-11 17:38 ` Paul Gortmaker
2013-06-11 17:53 ` Theodore Ts'o
2013-06-11 18:48 ` Paul Gortmaker
2013-06-11 21:54 ` Paul Gortmaker
2013-06-10 19:32 ` [PATCH 2/4] jbd2/log_wait_for_space: drop checkpoint mutex when waiting Paul Gortmaker
2013-06-11 2:33 ` Theodore Ts'o
2013-06-11 3:20 ` Paul Gortmaker
2013-06-11 13:03 ` Theodore Ts'o [this message]
2013-06-11 13:20 ` Paul Gortmaker
2013-06-10 19:32 ` [PATCH 3/4] jbd2: fix duplicate debug label for phase 2 Paul Gortmaker
2013-06-10 19:32 ` [PATCH 4/4] jbd/jbd2: relocate bit_spinlock header to jbd_common Paul Gortmaker
2013-06-10 23:38 ` [RFC PATCH 0/4] ext4/jbd2: several possible mainline fixes Theodore Ts'o
2013-06-11 3:09 ` Paul Gortmaker
2013-06-11 22:44 ` [PATCH v2 0/6] misc jbd2 fixes and cleanups Paul Gortmaker
2013-06-11 22:44 ` [PATCH 1/6] jbd2/journal_commit_transaction: relocate assert after state lock Paul Gortmaker
2013-06-13 2:42 ` Theodore Ts'o
2013-06-11 22:44 ` [PATCH 2/6] jbd2/log_wait_for_space: drop checkpoint mutex when waiting Paul Gortmaker
2013-06-13 2:55 ` Theodore Ts'o
2013-06-11 22:44 ` [PATCH 3/6] jbd2: fix duplicate debug label for phase 2 Paul Gortmaker
2013-06-13 2:57 ` Theodore Ts'o
2013-06-11 22:44 ` [PATCH 4/6] jbd/jbd2: relocate bit_spinlock header to jbd_common Paul Gortmaker
2013-06-13 3:02 ` Theodore Ts'o
2013-06-11 22:44 ` [PATCH 5/6] jbd2: make jbd_debug that won't split printk statements Paul Gortmaker
2013-06-11 22:44 ` [PATCH 6/6] jbd2: remove debug dependency on debug_fs; update help text Paul Gortmaker
2013-06-13 3:08 ` Theodore Ts'o
2013-06-13 13:51 ` Paul Gortmaker
2013-06-13 14:14 ` Theodore Ts'o
2013-06-13 14:47 ` Paul Gortmaker
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=20130611130333.GD23966@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
/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).