On Sun, Mar 15, 2009 at 12:57 AM, Greg Freemyer <[email protected]> wrote: > On Sat, Mar 14, 2009 at 2:55 PM, Vineet Agarwal > <[email protected]> wrote: >> hello Greg, >> >> sorry i didn't followed it right >> >> Now it's done. this is the output.. >> >> [r...@fscops Memcopy]# time (cp /test_256.db /mnt; sync) >> real 0m24.039s >> user 0m0.022s >> sys 0m1.566s >> > > Hmmm, still almost twice as fast. > > I assume the old time for the kernel module is still valid. ie. > Adding the 2 calls to sync and the drop_caches logic did not make much > difference. > >>> > time insmod mmcpy.ko inum=12 (without sync_dirty_buffers) > real 0m47.679s > user 0m0.002s > sys 0m12.838s >>> > > The 12 seconds of system time is very surprising. Please remind me, > how much data (in bytes) are you reading / writing per iteration? > > If it is not a multiple of 4K it can cause big inefficiencies. ie.
Hi Greg, As far as I know, they are reading block by block (in 4K blocksizes). Do you think readahead on the source inode would help ? We also looked at the source of "cp" and couldn't find anything special there. Thanks - Manish > The linux kernel uses a 4K page size and you want to try to use a > multiple of that for all i/o calls or things go bad from a performance > perspective. > > 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
