[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 18 Nov 2009 11:55:53 +0000
Thunderbird 220.127.116.11 (X11/20071008)
Thomas Denker wrote:
> Hi there,
> relax, I have not found a bug. But I have two questions
> which you may answer easily...
> Does the current version of "cp" make use of the "mmap"
> system call to accelerate access to the source or destination
I played around with various copy methods when writing:
/* I tested 3 methods for streaming large amounts of data to/from disk.
* All 3 took the same time as the bottleneck is the reading and writing to
* On x86 at least there is no significant difference between the AUTO and
* methods, the latter of which allocates the userspace buffer aligned on a
* There was a noticeable reduction in CPU usage when MMAP_WRITE was used,
* but the CPU usage is insignificant anyway due to the disc speeds we will
* generally be dealing with. I also noticed that the MMAP method was more
* giving consistent timings in all benchmark runs. However to ease portability
* I use the AUTO method below, which will also allow us to modify the MPEG
* required. For reference the timings for extracting a 338 MiB VOB
* from a VRO on the same hard disk were:
* real 0m30.650s
* user 0m0.007s
* sys 0m1.130s
* real 0m31.776s
* user 0m0.075s
* sys 0m1.803s
Note cp must be much more general/portable than my program so
I'm not sure mmap is appropriate.
> Does the current version of "cp" exploit the presence of
> multiple CPUs? (something like: one process copies the
> first half of the file, the other process the second..)
Not currently no. Again the bottleneck will probably be
the conduit to the storage and so multiprocessing within
a file will probably not be a win. If you have files on
separate storage then you can just run multiple cp processes
in parallel to do the copies.
- cp, Thomas Denker, 2009/11/17