Messages in this thread | | | Date | Sun, 18 Nov 2007 07:52:36 -0800 | From | "Abhishek Rai" <> | Subject | Re: [PATCH] Clustering indirect blocks in Ext3 |
| |
Thanks for the suggestion Matt.
It took me some time to get compilebench working due to the known issue with drop_caches due to circular lock dependency between j_list_lock and inode_lock (compilebench triggers drop_caches quite frequently). Here are the results for compilebench run with options "-i 30 -r 30". I repeated the test 5 times on each of vanilla and mc configurations.
Setup: 4 cpu, 8GB RAM, 400GB disk.
Average vanilla results ========================================================================== intial create total runs 30 avg 46.49 MB/s (user 1.12s sys 2.25s) create total runs 5 avg 12.90 MB/s (user 1.08s sys 1.97s) patch total runs 4 avg 8.70 MB/s (user 0.60s sys 2.31s) compile total runs 7 avg 21.44 MB/s (user 0.32s sys 2.95s) clean total runs 4 avg 59.91 MB/s (user 0.05s sys 0.26s) read tree total runs 2 avg 21.85 MB/s (user 1.12s sys 2.89s) read compiled tree total runs 1 avg 23.47 MB/s (user 1.45s sys 4.89s) delete tree total runs 2 avg 13.18 seconds (user 0.64s sys 1.02s) no runs for delete compiled tree stat tree total runs 4 avg 4.76 seconds (user 0.70s sys 0.50s) stat compiled tree total runs 1 avg 7.84 seconds (user 0.74s sys 0.54s)
Average metaclustering results ========================================================================== intial create total runs 30 avg 45.04 MB/s (user 1.13s sys 2.42s) create total runs 5 avg 15.64 MB/s (user 1.08s sys 1.98s) patch total runs 4 avg 10.50 MB/s (user 0.61s sys 3.11s) compile total runs 7 avg 28.07 MB/s (user 0.33s sys 4.06s) clean total runs 4 avg 83.27 MB/s (user 0.04s sys 0.27s) read tree total runs 2 avg 21.17 MB/s (user 1.15s sys 2.91s) read compiled tree total runs 1 avg 22.79 MB/s (user 1.38s sys 4.89s) delete tree total runs 2 avg 9.23 seconds (user 0.62s sys 1.01s) no runs for delete compiled tree stat tree total runs 4 avg 4.72 seconds (user 0.71s sys 0.50s) stat compiled tree total runs 1 avg 6.50 seconds (user 0.79s sys 0.53s)
Overall, metaclustering does better than vanilla except in a few cases.
Thanks, Abhishek
On Nov 15, 2007 11:37 PM, Matt Mackall <mpm@selenic.com> wrote: > On Thu, Nov 15, 2007 at 11:02:19PM -0800, Andrew Morton wrote: > > On Thu, 15 Nov 2007 21:02:46 -0800 "Abhishek Rai" <abhishekrai@google.com> wrote: > ... > > > 3. e2fsck speedup with metaclustering varies from disk > > > to disk with most benefit coming from disks which have a large number > > > of indirect blocks. For disks which have few indirect blocks, fsck > > > usually doesn't take too long anyway and hence it's OK not to deliver > > > a huge speedup there. But in all cases, metaclustering doesn't cause > > > any degradation in IO performance as seen in the benchmarks above. > > > > Less speedup, for more-and-smaller files, it appears. > > > > An important question is: how does it stand up over time? Simply laying > > files out a single time on a fresh fs is the easy case. But what happens > > if that disk has been in continuous create/delete/truncate/append usage for > > six months? > > Try Chris Mason's compilebench, which is a decent aging simulation. > > -- > Mathematics is the supreme nostalgia of our time. > - 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/
| |