On Fri, Mar 13, 2009 at 9:19 PM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote: > On Fri, Mar 13, 2009 at 11:23 AM, Vineet Agarwal > <checkout.vineet@xxxxxxxxx> wrote: >> Hello Everyone, >> >> Well i have tested the code of memcopy without sync_dirty_buffers() >> No data corruption was reported. So it is fine . >> But still the downtime for relocation is still high as compared to cp. >> >> test_256.db is a 256 Mb file that is relocated. >> >> [root@fscops Memcopy]# time cp /test_256.db /mnt >> real 0m17.577s >> user 0m0.017s >> sys 0m1.251s >> > > Vineet, > > You have to remember all the caches that are involved with disk i/o. > When benchmarking you have to ensure all the caches are empty before > AND after the timing is performed. > > ie. Having a copy of test_256.db in the cache before you start would > mean it does not have to be read from disk, but simply pulled from > ram. > > Not emptying the cache at the end means all that your timing is the > population of the write cache. Need to include the time it takes to > get the data to disk. > > I can't remember offhand how to flush the read cache By any chance it is setting 1 to /proc/sys/vm/drop_caches ?? Thanks - Manish >, but you can > flush the write cache by calling sync. > > So I would modify your cp benchmark to at least do: > > sync; > time (cp /tmp/test_256.db /tmp/junk; sync) > > But as I say the read cache is likely to have a copy of test_256.db > already in it, so you can't trust even the above. > > What I typically do is to use a test file several times the size of my > RAM, then run a test like the above several times in a row. Because > the test file is much bigger than you cache, it is a pretty safe > _assumption_ that you don't have any useful data in the cache to > accelerate the read. > > Once you get a more accurate cp benchmark, then please redo the kernel > module test as: > > sync > time (insmod mmcpy.ko inum=12; sync) > > It is important to note that the above are very basic benchmarking > techniques. To properly benchmark you need to control the details of > the cache much more so, but for the purposes of comparing these 2 > methods I think the above should be fine. > > Good luck, > Greg > -- > Greg Freemyer > Head of EDD Tape Extraction and Processing team > Litigation Triage Solutions Specialist > http://www.linkedin.com/in/gregfreemyer > First 99 Days Litigation White Paper - > http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf > > The Norcross Group > The Intersection of Evidence & Technology > http://www.norcrossgroup.com > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
