From: Nick Piggin <npiggin@kernel.dk>
To: Jan Kara <jack@suse.cz>
Cc: Nick Piggin <npiggin@kernel.dk>,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@ZenIV.linux.org.uk>,
linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org,
Eric Sandeen <sandeen@redhat.com>, Theodore Ts'o <tytso@mit.edu>
Subject: Re: [patch] fs: fix deadlocks in writeback_if_idle
Date: Thu, 25 Nov 2010 14:52:45 +1100 [thread overview]
Message-ID: <20101125035245.GB3359@amd> (raw)
In-Reply-To: <20101123131857.GG6113@quack.suse.cz>
On Tue, Nov 23, 2010 at 02:18:57PM +0100, Jan Kara wrote:
> On Tue 23-11-10 21:11:49, Nick Piggin wrote:
> > The issue of writeback_inodes_sb being synchronous so far as it has to
> > wait until the work has been dequeued is another subtlety. That is a
> > funny interface though, really. It has 3 callers, sync, quota, and
> > ubifs. From a quick look, quota and ubifs seem to think it is some kind
> > of synchronous writeout API.
> Yes, they expect it and it used to be the case before per-bdi flusher
> threads existed (because the function submitted IO on its own). Then it
> was changed to an async interface in per-bdi flusher thread patches and
> then back again to a synchronous one... Sad history...
>
> > It also really sucks that it can get deadlocked behind an unrelated item
> > in a workqueue. I think it should just get converted over to the
> > async-submission style as well.
> Here I don't quite agree. After my patches (currently in -mm tree) all
> work items have reasonably well defined lifetime so no livelocks should
> occur.
It was actually a deadlock, and it was due to workqueue item for
writeback submission being held up behind item for completion, where
former is holding i_mutex and latter trying to acquire.
I haven't studied the patches in -mm, do they solve this problem?
> After all writeback thread is doing its best to do as much IO as
> possible (and hopefully saturates the storage) so given all the IO work
> items we cannot do much better. Where I see a room for improvement is
> that work items usually try to achieve a common goal - for example when we
> get two items "write all dirty pages", we have mostly fulfilled the second
> one after finishing the first one but we start from the beginning when
> processing the second request. But it seems non-trivial to do this request
> merging especially for different types of requests...
Well the request is still going via normal writeback submission. The
difference in my patch is that we just dynamically allocate it and don't
pass a pointer to sb, so we don't have to wait.
next prev parent reply other threads:[~2010-11-25 3:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 10:02 [patch] fs: fix deadlocks in writeback_if_idle Nick Piggin
2010-11-23 10:11 ` Nick Piggin
2010-11-23 13:18 ` Jan Kara
2010-11-25 3:52 ` Nick Piggin [this message]
2010-11-23 10:26 ` Boaz Harrosh
2010-11-23 10:54 ` Nick Piggin
2010-11-23 12:00 ` Boaz Harrosh
2010-11-23 12:34 ` Chris Mason
2010-11-23 12:52 ` Nick Piggin
2010-11-23 18:58 ` Chris Mason
2010-11-24 1:03 ` Nick Piggin
2010-11-24 13:10 ` Jan Kara
2010-11-25 3:53 ` Nick Piggin
2010-11-29 22:26 ` Andrew Morton
2010-11-30 0:01 ` Nick Piggin
2010-12-16 3:12 ` Nick Piggin
2010-11-24 22:51 ` Andrew Morton
2010-11-25 4:07 ` Nick Piggin
2010-11-24 22:47 ` Andrew Morton
2010-11-25 9:41 ` Boaz Harrosh
2010-11-25 20:30 ` Andrew Morton
2010-11-30 0:50 ` Chris Mason
2010-11-23 12:54 ` Dmitry
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=20101125035245.GB3359@amd \
--to=npiggin@kernel.dk \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
--cc=viro@ZenIV.linux.org.uk \
/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).