On Fri, Mar 13, 2009 at 11:58 AM, Manish Katiyar <[email protected]> wrote: > On Fri, Mar 13, 2009 at 9:19 PM, Greg Freemyer <[email protected]> > wrote: >> On Fri, Mar 13, 2009 at 11:23 AM, Vineet Agarwal >> <[email protected]> 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. >>> >>> [r...@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 ?? >
Looks right. Per http://linux-mm.org/Drop_Caches Your script should have: # flush the dirty blocks out to disk sync # flush the cache of all non-dirty blocks. ie. flush the read cache echo 3 > /proc/sys/vm/drop_caches # time the actual copy time (....; sync) 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 [email protected] Please read the FAQ at http://kernelnewbies.org/FAQ
