Re: cp

[Pádraig Brady]

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
> file?

I played around with various copy methods when writing:
http://www.pixelbeat.org/programs/dvd-vr/dvd-vr-0.9.3.tar.gz
and commented...

/* 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 
disk.
 * On x86 at least there is no significant difference between the AUTO and 
ALLOC_ALIGN
 * methods, the latter of which allocates the userspace buffer aligned on a 
page.
 * 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 
stable
 * giving consistent timings in all benchmark runs. However to ease portability 
worries
 * I use the AUTO method below, which will also allow us to modify the MPEG 
frames if
 * required. For reference the timings for extracting a 338 MiB VOB
 * from a VRO on the same hard disk were:
 *
 *     MMAP_WRITE
 *       real    0m30.650s
 *       user    0m0.007s
 *       sys     0m1.130s
 *     AUTO/ALLOC_ALIGN
 *       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.

cheers,
Pádraig.