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.
