linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Matthew Wilcox <willy@linux.intel.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: Livelock when running xfstests generic/127 on ext4 with 3.15
Date: Wed, 25 Jun 2014 10:45:14 -0400	[thread overview]
Message-ID: <20140625144514.GA10397@thunk.org> (raw)
In-Reply-To: <20140625141756.GS12025@linux.intel.com>

On Wed, Jun 25, 2014 at 10:17:56AM -0400, Matthew Wilcox wrote:
> 
> Okay ... but why is it so much worse in 3.15 than 3.14?
> 
> And does ext4 think of "running out of space" as a percentage
> free, or an absolute number of blocks remaining?  From the code in
> ext4_nonda_switch(), it seems to be the former, although maybe excessive
> fragmentation has caused ext4 to think it's running out of space?

When the blocks that were allocated using delayed allocation exceeds
50% of the free space, we initiate writeback.  When delalloc blocks
exceeds 66% of the free space, we fall back to nodelalloc, which among
other things, means blocks are allocated for each write system call,
and we also have to add and remove the inode from on the orphan inode
list so that if we crash in the middle of the write system call, we
don't end up exposing stale data.

We did have a change to the orphan inode code to improve scalability,
so that could have been a possible cause; but that happened after
3.15, so that can't be it.  The other possibility is that there's
simply a chance in the writeback code that is changing how
aggressively we start writeback when we exceed the 50% threshold, so
that we end up switching into nonda mode more often.

Any chance you can run generic/127 under perf so we can see where
we're spending all of our CPU time?  The other thing I can imagine
doing is to add tracepoint when whenver we drop into nonda mode, so we
can see if that's happening more often under 3.15 versus 3.14.

    	   	  	    	       	     - Ted

      parent reply	other threads:[~2014-06-25 14:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-20 17:53 Livelock when running xfstests generic/127 on ext4 with 3.15 Matthew Wilcox
2014-06-25 13:12 ` Jan Kara
2014-06-25 14:17   ` Matthew Wilcox
2014-06-25 14:44     ` Jan Kara
2014-06-25 14:45     ` Theodore Ts'o [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=20140625144514.GA10397@thunk.org \
    --to=tytso@mit.edu \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=willy@linux.intel.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).