From: Wu Fengguang <fengguang.wu@intel.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Dave Chinner <david@fromorbit.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"bugzilla-daemon@bugzilla.kernel.org"
<bugzilla-daemon@bugzilla.kernel.org>,
"daaugusto@gmail.com" <daaugusto@gmail.com>,
"kernel-bugzilla@cygnusx-1.org" <kernel-bugzilla@cygnusx-1.org>,
"listposter@gmail.com" <listposter@gmail.com>,
"justincase@yopmail.com" <justincase@yopmail.com>,
"clopez@igalia.com" <clopez@igalia.com>, Tao Ma <tm@tao.ma>,
Jens Axboe <axboe@kernel.dk>, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [Bug 18632] "INFO: task" dpkg "blocked for more than 120 seconds.
Date: Thu, 9 Jun 2011 20:11:17 +0800 [thread overview]
Message-ID: <20110609121117.GA5768@localhost> (raw)
In-Reply-To: <20110609110214.GA9017@infradead.org>
On Thu, Jun 09, 2011 at 07:02:14PM +0800, Christoph Hellwig wrote:
> On Thu, Jun 09, 2011 at 05:09:06PM +0800, Wu Fengguang wrote:
> > I have a sync livelock test script and it sometimes livelocked on XFS
> > even with the livelock fix patches. Ext4 is always OK.
>
> This sounds similar to the cfq issue just posted to lkml as
> "CFQ: async queue blocks the whole system".
I once ran two dd's doing sequential reads and writes in parallel, and
find the write dd to be completely blocked (note: I can no longer
reproduce it today, on 3.0-rc2). At the time I thought: "Wow, this is
good for typical desktop". But yes, it is livelocking async IOs, which
is bad.
> Does this happen with non-CFQ I/O schedulers, too?
Just tried the deadline scheduler, sync times are still long:
echo deadline > /sys/block/sda/queue/scheduler
sync time: 21
sync time: 22
sync time: 29
Also tried disabling the cfq low latency feature,
echo cfq > /sys/block/sda/queue/scheduler
echo 0 > /sys/block/sda/queue/iosched/low_latency
However the low_latency value seem to have NO much effects in the
sync time (and also don't considerably improve async dd write
bandwidth at the presence of another parallel dd read).
sync time: 19
sync time: 24
sync time: 22
> > [ 3581.185120] [<ffffffff812ed520>] xfs_ioend_wait+0x87/0x9f
>
> This waits for the I/O completion to actually arrive - something that
> XFS does correctly in both sync and fsync, but ext4 only does for fsync.
Will it benefit to flush the disk _once_ at the end of sync?
(perhaps it's not be as easy in complex storage setups or whatever)
> It might have some issues in the way it's implemented, I'll look if
> we can do something. But I suspect cfq delaying async writes too much
> is definitively going to cause issues for us here.
It's definitely a problem that cfq delays async writes too much.
However in Carlos's report,
https://bugzilla.kernel.org/attachment.cgi?id=61222
there are no sync(1) or fsync running at all. So it may be indicating
a different problem.
Thanks,
Fengguang
next prev parent reply other threads:[~2011-06-09 12:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-18632-27@https.bugzilla.kernel.org/>
[not found] ` <201106082138.p58Lchgj002615@demeter2.kernel.org>
[not found] ` <20110608150241.8412a63d.akpm@linux-foundation.org>
2011-06-09 3:32 ` [Bug 18632] "INFO: task" dpkg "blocked for more than 120 seconds Wu Fengguang
2011-06-09 3:54 ` Wu Fengguang
2011-06-09 8:27 ` Christoph Hellwig
2011-06-09 9:09 ` Wu Fengguang
2011-06-09 11:02 ` Christoph Hellwig
2011-06-09 12:11 ` Wu Fengguang [this message]
2011-06-09 12:17 ` Wu Fengguang
2011-06-09 12:17 ` Christoph Hellwig
2011-06-09 12:43 ` Wu Fengguang
2011-06-09 13:23 ` Christoph Hellwig
2011-06-10 3:21 ` Wu Fengguang
2011-06-19 15:56 ` Christoph Hellwig
2011-06-19 16:33 ` Wu Fengguang
2011-06-09 13:56 ` Tao Ma
2011-06-09 14:12 ` Tao Ma
2011-06-09 14:21 ` Christoph Hellwig
2011-06-09 14:32 ` Vivek Goyal
2011-06-09 14:51 ` Tao Ma
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=20110609121117.GA5768@localhost \
--to=fengguang.wu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=clopez@igalia.com \
--cc=daaugusto@gmail.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=justincase@yopmail.com \
--cc=kernel-bugzilla@cygnusx-1.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=listposter@gmail.com \
--cc=tm@tao.ma \
--cc=vgoyal@redhat.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).