question about splice performance

question about splice performance

[Francis Moreau]

Hi,

I did a really basic benchmark and was suprise about the results.

$ echo 3 > /proc/sys/vm/drop_caches
$ time  splice-cp  vmlinux /tmp/vmlinux

real    0m10.158s
user    0m0.002s
sys     0m0.401s

$ echo 3 > /proc/sys/vm/drop_caches
$ time  cp  vmlinux /tmp/vmlinux

real    0m10.590s
user    0m0.017s
sys     0m0.459s


I was expecting splice-cp case to be faster.

Could someone enlight me ?

Thanks
-- 
Francis

Re: question about splice performance

[Jan Engelhardt]

On Sunday 2008-05-25 17:12, Francis Moreau wrote:

>Hi,
>
>I did a really basic benchmark and was suprise about the results.
>
>$ echo 3 > /proc/sys/vm/drop_caches
>$ time  splice-cp  vmlinux /tmp/vmlinux
>
>real    0m10.158s
>user    0m0.002s
>sys     0m0.401s
>
>$ echo 3 > /proc/sys/vm/drop_caches
>$ time  cp  vmlinux /tmp/vmlinux
>
>real    0m10.590s
>user    0m0.017s
>sys     0m0.459s
>
>
>I was expecting splice-cp case to be faster.
>
>Could someone enlight me ?

Slow disk outweighs memory copying overhead. And 300 MB is quickly
transferred in idle systems.

Re: question about splice performance

[Sitsofe Wheeler]

<posted & mailed>

Francis Moreau wrote:

> Hi,
> 
> I did a really basic benchmark and was suprise about the results.
> 
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time  splice-cp  vmlinux /tmp/vmlinux

Are vmlinux and /tmp both RAM filesystems? If not you may want to try
using /dev/shm to rule out disk speed...

-- 
Sitsofe | http://sucs.org/~sits/

Re: question about splice performance

[Jeff Garzik]

Francis Moreau wrote:
> Hi,
> 
> I did a really basic benchmark and was suprise about the results.
> 
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time  splice-cp  vmlinux /tmp/vmlinux
> 
> real    0m10.158s
> user    0m0.002s
> sys     0m0.401s
> 
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time  cp  vmlinux /tmp/vmlinux
> 
> real    0m10.590s
> user    0m0.017s
> sys     0m0.459s
> 
> 
> I was expecting splice-cp case to be faster.
> 
> Could someone enlight me ?

If you drop caches you are not measuring splice speed.

Use ramfs for your tests (guarantees data is in cache) instead.

	Jeff

Re: question about splice performance

[Francis Moreau]

Hello,

On Sun, May 25, 2008 at 10:47 PM, Jeff Garzik <jeff@garzik.org> wrote:
>
> If you drop caches you are not measuring splice speed.
>
> Use ramfs for your tests (guarantees data is in cache) instead.
>

So it seems that the gain when using splice to copy a file into another file
is very limited. Maybe that's the reason why cp is still using read/write...

Also splice-cp uses 2 calls to splice syscall in a loop. So it end up doing a
lot of syscalls. Maybe using sendfile instead of is better.

Also2, since splice is a generalized pipe, it might be better to create to
processes, one writing to the pipe and the other one reading to have better
workflow.

That said I also see some use cases where splice could be more useful,
specially when one of the file descriptor is actually a device: one the write
side of the pipes a device could write some data while on the other side of
the pipe a process can empty the pipe by writing the data to a file.

Are there any plans to improve splice interface to be used by drivers ?

Thanks.
-- 
Francis

Re: question about splice performance

[Bernd Petrovitsch]

Hi!

On Mon, 2008-05-26 at 10:57 +0200, Francis Moreau wrote:
> On Sun, May 25, 2008 at 10:47 PM, Jeff Garzik <jeff@garzik.org> wrote:
> >
> > If you drop caches you are not measuring splice speed.
> >
> > Use ramfs for your tests (guarantees data is in cache) instead.
> 
> So it seems that the gain when using splice to copy a file into another file
> is very limited. Maybe that's the reason why cp is still using read/write...

To point it out one more time: If you copy from one file on a physical
harddisk (or more or less similar hardware) to another (with cold
caches), the bottleneck is most probably the harddisk.

splice() simply reduces the amount of copied data in the RAM - and that
is practically irrelevant if you read and write to and from harddisks.

So if you want to measure the savings of using splice() (instad of
read()/write(), etc.): Copy to and from RAM disks (and thus rule out the
slow hardware).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services