linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: Jan Kara <jack@suse.cz>
Cc: john stultz <johnstul@us.ibm.com>,
	linux-ext4@vger.kernel.org, Mingming Cao <cmm@us.ibm.com>,
	keith maanthey <kmannth@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	Darren Hart <dvhltc@us.ibm.com>
Subject: Re: ext4 dbench performance with CONFIG_PREEMPT_RT
Date: Tue, 13 Apr 2010 10:52:47 -0400	[thread overview]
Message-ID: <20100413145247.GO1849@thunk.org> (raw)
In-Reply-To: <20100412194628.GI12238@atrey.karlin.mff.cuni.cz>

On Mon, Apr 12, 2010 at 09:46:28PM +0200, Jan Kara wrote:
>   I also had a look at jbd2_journal_start. What probably makes
> things bad there is that lots of threads accumulate waiting for
> transaction to get out of T_LOCKED state. When that happens, all the
> threads are woken up and start pondering at j_state_lock which
> creates contention. This is just a theory and I might be completely
> wrong... Some lockstat data would be useful to confirm / refute
> this.

Yeah, that sounds right.  We do have a classic thundering hurd problem
when we while are draining handles from the transaction in the
T_LOCKED state --- that is (for those who aren't jbd2 experts) when it
comes time to close out the current transaction, one of the first
things that fs/jbd2/commit.c will do is to set the transaction into
T_LOCKED state.  In that state we are waiting for currently active
handles to complete, and we don't allow any new handles to start until
the currently running transaction is completely drained of active
handles, at which point we can swap in a new transaction, and continue
the commit process on the previously running transaction.

On a non-real time kernel, the spinlock will tie up the currently
running CPU's until the transaction drains, which is usually pretty
fast, since we don't allow transactions to be held for that long (the
worst case being truncate/unlink operations).  Dbench is a worst case,
though since we have some large number of threads all doing file
system I/O (John, how was dbench configured?) and the spinlocks will
no longer tie up a CPU, but actually let some other dbench thread run,
so it magnifies the thundering hurd problem from 8 threads, to nearly
all of the CPU threads.

Also, the spinlock code has a "ticket" system which tries to protect
against the thundering hurd effect --- do the PI mutexes which replace
spinlocks in the -rt kernel have any technqiue to try to prevent
scheduler thrashing in the face of thundering hurd scenarios?

	  	       	   	   - Ted

  reply	other threads:[~2010-04-14  3:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-07 23:21 ext4 dbench performance with CONFIG_PREEMPT_RT john stultz
2010-04-08  3:46 ` tytso
2010-04-08 10:18   ` Theodore Tso
2010-04-08 20:41   ` john stultz
2010-04-08 21:10     ` tytso
2010-04-13  3:52       ` john stultz
2010-04-14  3:04       ` john stultz
2010-04-08 22:37   ` Mingming Cao
2010-04-12 19:46   ` Jan Kara
2010-04-13 14:52     ` tytso [this message]
2010-04-13 16:25       ` Darren Hart
2010-06-02 22:35       ` j_state_lock patch data (was: Re: ext4 dbench performance with CONFIG_PREEMPT_RT) Eric Whitney
2010-04-09 15:49 ` ext4 dbench performance with CONFIG_PREEMPT_RT Andi Kleen
2010-04-09 23:33   ` tytso
2010-04-09 23:48     ` Chen, Tim C
2010-04-09 23:57       ` john stultz
2010-04-10 11:58       ` tytso
2010-04-12 19:54         ` Chen, Tim C

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=20100413145247.GO1849@thunk.org \
    --to=tytso@mit.edu \
    --cc=cmm@us.ibm.com \
    --cc=dvhltc@us.ibm.com \
    --cc=jack@suse.cz \
    --cc=johnstul@us.ibm.com \
    --cc=kmannth@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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).