On 10/25/2012 05:20 PM, Miao Xie wrote: > This patchset introduce multi-task delalloc flush, it can make the delalloc > flush more faster. And besides that, it also can fix the problem that we join > the same transaction handler more than 2 times. > > Implementation: > - Create a new worker pool. > - Queue the inode with pending delalloc into the work queue of the worker pool > when we want to force them into the disk, and then we will wait till all the > works we submit are done. > - The ordered extents also can be queued into this work queue. The process is > similar to the second one. >
I can see the potential improvements brought by flushing inodes this way. But I don't think it makes much sense by making waiting process multi-task, since even we spread wait order extents into different cpus, they just occpied the cpu and went on waiting and scheduled then, I mean, the bottleneck is on what we're waiting for. Besides, considering that this patchset is about to getting us better performance, I'm expecting any performance numbers (I'm a little worried about context switches overhead). btw, cool ideas indeed. thanks, liubo > Miao Xie (3): > Btrfs: make delalloc inodes be flushed by multi-task > Btrfs: make ordered operations be handled by multi-task > Btrfs: make ordered extent be flushed by multi-task > > fs/btrfs/ctree.h | 14 +++++++ > fs/btrfs/disk-io.c | 7 ++++ > fs/btrfs/inode.c | 78 ++++++++++++++++++++++++++++++++++++++--- > fs/btrfs/ordered-data.c | 87 > ++++++++++++++++++++++++++++++++++------------- > fs/btrfs/ordered-data.h | 7 +++- > fs/btrfs/relocation.c | 6 +++- > fs/btrfs/transaction.c | 24 ++++++++++--- > 7 files changed, 185 insertions(+), 38 deletions(-) > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
