On Sat, Jul 11, 2009 at 5:44 AM, Doug Ledford<dledford@xxxxxxxxxx> wrote: > Thanks. This isn't too far off from what I would expect. I would say that > real world loads fall all along a spectrum from "create lots of writes, but > do little to no work" to "does lots of work, and only sporadically writes". > It's the later end of this spectrum that is most likely to be helped by the > cache avoiding routines, while the former is not. So, one of the tests I > had in mind was to use something like timing a complete kernel build, or > doing a database load/report cycle, or some other things like that. Things > that do actual work in the foreground while the raid is kept busy in the > background. Of course, testing all the various points along the spectrum is > needed, so this test gets us the first. This reminds of the testing I did when quantifying the benefit of hardware accelerated raid5. I played with kernel builds while resyncing to show the cache and cpu-utilization savings, but never got that to settle on a solid number. I took a look at Con Kolivas' "contest" benchmark [1], but ultimately just published plain iozone data [2]. The interesting bit is that cpu limited random writes saw more throughput improvement than streaming writes because the i/o processing did not need to compete with management of the stripe cache. -- Dan [1]: http://users.on.net/~ckolivas/contest/ [2]: http://sourceforge.net/projects/xscaleiop/files/MD RAID Acceleration/iop-iozone-graphs-20061010.tar.bz2/download -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
