On Fri, 26 Oct 2012 10:05:55 +0800, Liu Bo wrote:

On 10/26/2012 09:56 AM, Miao Xie wrote:

quoted

quoted

I can see the potential improvements brought by flushing inodes this way.

quoted

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.

Thanks for your comment, I think only btrfs_run_ordered_operations(root, 0) needn't
wait for the works, the others must wait.

The first reason is to avoid changing the semantic of those tree function. The second
reason is we have to wait for the completion of all works, if not, the file data in
snapshots may be different with the source suvolumes because the flush may not end
before the snapshot creation.

Yes, it's right that they must wait for all workers to finish.

But I don't mean that(sorry for my confusing words).

IMO we don't need to let *btrfs_wait_ordered_extents()* run as multi-task.

It also need to be done by multi-task because btrfs_wait_ordered_extents() doesn't imply
that all the dirty pages in the ordered extent have been written into the disk, that is
it also need do lots of things before waiting for the event - BTRFS_ORDERED_COMPLETE, so
the multi-task process is useful, I think.

Anyway, we need test to validate it.

Thanks
Miao

thanks,
liubo