Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752558Ab1EJB72 (ORCPT ); Mon, 9 May 2011 21:59:28 -0400 Received: from mail.parknet.co.jp ([210.171.160.6]:38884 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751775Ab1EJB70 (ORCPT ); Mon, 9 May 2011 21:59:26 -0400 From: OGAWA Hirofumi To: "Darrick J. Wong" Cc: Theodore Tso , Jan Kara , Alexander Viro , Jens Axboe , "Martin K. Petersen" , Jeff Layton , Dave Chinner , linux-kernel , Dave Hansen , Christoph Hellwig , linux-mm@kvack.org, Chris Mason , Joel Becker , linux-scsi , linux-fsdevel , linux-ext4@vger.kernel.org, Mingming Cao Subject: Re: [PATCHSET v3.1 0/7] data integrity: Stabilize pages during writeback for various fses References: <20110509230318.19566.66202.stgit@elm3c44.beaverton.ibm.com> Date: Tue, 10 May 2011 10:59:15 +0900 In-Reply-To: <20110509230318.19566.66202.stgit@elm3c44.beaverton.ibm.com> (Darrick J. Wong's message of "Mon, 09 May 2011 16:03:18 -0700") Message-ID: <87tyd31fkc.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2272 Lines: 44 "Darrick J. Wong" writes: > To assess the performance impact of stable page writes, I moved to a disk that > doesn't have DIF support so that I could measure just the impact of waiting for > writeback. I first ran wac with 64 threads madly scribbling on a 64k file and > saw about a 12 percent performance decrease. I then reran the wac program with > 64 threads and a 64MB file and saw about the same performance numbers. As I > suspected, the patchset only seems to impact workloads that rewrite the same > memory page frequently. > > I am still chasing down what exactly is broken in ext3. data=writeback mode > passes with no failures. data=ordered, however, does not pass; my current > suspicion is that jbd is calling submit_bh on data buffers but doesn't call > page_mkclean to kick the userspace programs off the page before writing it. > > Per various comments regarding v3 of this patchset, I've integrated his > suggestions, reworked the patch descriptions to make it clearer which ones > touch all the filesystems and which ones are to fix remaining holes in specific > filesystems, and expanded the scope of filesystems that got fixed. > > As always, questions and comments are welcome; and thank you to all the > previous reviewers of this patchset. I am also soliciting people's opinions on > whether or not these patches could go upstream for .40. I'd like to know those patches are on what state. Waiting in writeback page makes slower, like you mentioned it (I guess it would more noticeable if device was slower that like FAT uses). And I think currently it doesn't help anything others for blk-integrity stuff (without other technic, it doesn't help FS consistency)? So, why is this locking stuff enabled always? I think it would be better to enable only if blk-integrity stuff was enabled. If it was more sophisticate but more complex stuff (e.g. use copy-on-write technic for it), I would agree always enable though. Thanks. -- OGAWA Hirofumi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/