On Friday 15 February 2008, Dongjun Shin wrote: > Hello, > > When I'm running postmark on btrfs v0.12, although the system > must be busy doing the I/O, there are some cases where the I/O is idle > while btrfs workqueue eats up most of the CPU time. > > It seems that this happens for both 2.6.23 and 2.6.24 kernel. > > Any idea? >
It is probably the defrag process or snapshot deletion holding the FS wide mutex and excluding other writeback. This big mutex is really sub-optimal, and it shows up on a number of benchmarks. (sysrq-p might catch it) Once the multiple device code is ready, fine grained locking is my top priority. For runs like postmark, a smaller blocksize (mkfs.btrfs -l 4096 -n 4096) will lower the amount of work that needs to be done during snapshot deletion. Random IOs cause more btree churn on the larger blocksizes. You could also try the patch below to disable defrag in ssd mode. -chris
diff -r a503a3f82684 tree-defrag.c --- a/tree-defrag.c Fri Feb 08 13:49:28 2008 -0500 +++ b/tree-defrag.c Fri Feb 15 09:57:57 2008 -0500 @@ -179,6 +179,9 @@ int btrfs_defrag_leaves(struct btrfs_tra if (root->ref_cows == 0 && !is_extent) goto out; + if (btrfs_test_opt(root, SSD)) + goto out; + path = btrfs_alloc_path(); if (!path) return -ENOMEM;
_______________________________________________ Btrfs-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/btrfs-devel
