"Darrick J. Wong" <djwong@xxxxxxxxxx> 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 <hirofumi@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
