[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwZHOUCYvojbP9q3D5MDgCH7GttkUGiJerra9uyduFLKw@mail.gmail.com>
Date: Tue, 2 Jul 2013 09:13:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jan Kara <jack@...e.cz>
Cc: Dave Chinner <david@...morbit.com>, Dave Jones <davej@...hat.com>,
Oleg Nesterov <oleg@...hat.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Andrey Vagin <avagin@...nvz.org>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: frequent softlockups with 3.10rc6.
On Tue, Jul 2, 2013 at 7:05 AM, Jan Kara <jack@...e.cz> wrote:
> On Tue 02-07-13 22:38:35, Dave Chinner wrote:
>>
>> IOWs, sync is 7-8x faster on a busy filesystem and does not have an
>> adverse impact on ongoing async data write operations.
> The patch looks good. You can add:
> Reviewed-by: Jan Kara <jack@...e.cz>
Ok, I'm going to take this patch asap. Should we also mark it for
stable? It doesn't look like a regression in that particular code, but
it sounds like it might be a regression when paired with the way the
flusher threads interact. Or is this really some long-time performance
problem?
I'm also wondering if we should just change all callers - remove that
"wait for writeback to complete" from writeback_one_inode()
completely, and just make sure that *all* callers that use WB_SYNC_ALL
do the "wait for writeback" in a separate stage, the way "sync()"
already does? That whole
if (wbc->sync_mode == WB_SYNC_ALL && !wbc->for_sync) {
test doesn't really look all that sane (..so thanks Dave for adding a
comment above it)
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists