Re: [ext2/ext3] Re-allocation of blocks for an inode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Mar 14, 2009 at 2:55 PM, Vineet Agarwal
<checkout.vineet@xxxxxxxxx> wrote:
> hello Greg,
>
> sorry i didn't followed it right
>
> Now it's done. this is the output..
>
> [root@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.
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 ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux