LWN: Comments on "Two new system calls: splice() and sync_file_range()"

heavy-duty philosophy

xoddam — 2006-04-10T01:03:58+00:00

> splice() must truly be a great philosopher!

This is an in-joke, from the text adventure game version of Douglas
Adams' Hitch-Hiker's Guide to the Galaxy:

>open door
The door explains, in a haughty tone, that the room is occupied
by a super-intelligent robot and that lesser beings (by which
it means you) are not to be admitted. "Show me some tiny example
of your intelligence," it says, "and maybe, just maybe, I might
reconsider."

>get tea
no tea: Dropped.

>get no tea
no tea: Taken.

>inventory
You have:
no tea
tea
a small key
a flowerpot
a thing your aunt gave you which you don't know what it is
a babel fish (in your ear)

>open door
The door is almost speechless with admiration. "Wow. Simultaneous
tea and no tea. My apologies. You are clearly a heavy-duty
philosopher." It opens respectfully.

It is zero-copy

axboe — 2006-04-08T18:26:26+00:00

Copy is in quotes, because it's not the CPU doing the copy. Which is what is interesting, and why zero-copy just means zero CPU copies. That is where you pay the cost, at least in CPU cycles and potentially also in cache. So zero-copy definitely isn't just a play on words. It may sometimes be used in silly marketing ways, but if you are CPU bound it makes all the difference in the world that the CPU doesn't have to touch the data.

And yes, the normal copy is indeed two copies, to and from kernel/user space.

You can continue talking if you want, but don't expect a response from me.

It is zero-copy

giraffedata — 2006-04-08T17:31:39+00:00

So a splice based copy will be zero memory copies, and two DMA "copies"

I presume "copies" is in quotes because you agree with me that the DMA operations are not copies in the sense we're talking about. (If they were, a "zero-copy" file read wouldn't be zero-copy, and moving data from kernel file data cache to user space would be two copies (kernel memory to register, register to user memory)).

However, the combination of the two DMAs constitutes one disk copy. A disk copy is an instance of replicating data from one place on a disk to another, just as a memory copy is an instance of replicating data from one place in memory to another. And it's worth talking about because it takes time. If you could truly do a zero-copy copy, that would be remarkable. As it stands, "zero-copy copy" is just a trick of words in which you change the definition of copy in the middle of the sentence.

A normal copy contains the same number of DMA operations, but includes a memory copy.

Actually, the most normal file copy includes two memory copies -- from kernel file data cache of the source file to user space buffer, and from that buffer to the other file's kernel file data cache. With mmap, you can get it down to one, and with direct I/O you can get to zero.

It is zero-copy

axboe — 2006-04-08T11:14:34+00:00

A splice based copy does no copies. The source data is DMA'ed from hardware to the source file page(s), then those pages are moved to the destination and dirted to so will eventually go out to disk again with another DMA operations.

A normal copy will DMA those pages in, allocate pages in the target file address space, copy that data over, and then it'll be DMA'ed to disk again. So two DMA operations, and one full copy of all the data.

So a splice based copy will be zero memory copies, and two DMA "copies" (the dma operation above may be a series of dma transactions, depending on how large the file is). A normal copy contains the same number of DMA operations, but includes a memory copy.

It is zero-copy

giraffedata — 2006-04-07T22:46:27+00:00

It sounds funny only because you're using "copy" two different ways in the same sentence. When we talk about copying a file, we're talking about copying from disk to disk. When we say zero-copy, we're talking about copying data from memory to memory.

A splice-based file copy does one disk-disk copy, and no memory-memory copy, as contrasted with the traditional file copy that does one disk-disk copy plus two memory-memory copies.

Since the naive observer wouldn't even expect there to be memory-memory copies involved in copying files, "zero copy file copy" shouldn't sound odd at all.

It is zero-copy

axboe — 2006-04-06T07:16:33+00:00

> Wow! Copying without copying! splice() must truly be a great philosopher!

Yeah it sounds crazy, but it's really true :-). You bring in the pages from the source file, then migrate them to the address space of the target file. Bingo, zero copy copies!

It is zero-copy

xoddam — 2006-04-06T06:42:27+00:00

> It is zero-copy

Sorry -- I misremembered Linus' original pipe-buffer
discussion. It has been a while:

http://lwn.net/Articles/118760/

> Splice can even do zero-copy file copies

Wow! Copying without copying! splice() must truly be a great philosopher!

It is zero-copy

axboe — 2006-04-06T05:59:33+00:00

It is zero-copy, why do you think the pipe pages are copied before being transmitted? Splice can even do zero-copy file copies, by moving pages from one file to another.

And what becomes of zero-copy?

xoddam — 2006-04-06T01:13:53+00:00

> The splice git branch has support for fd -> fd splicing now
> (by using a virtual pipe), so sys_sendfile can basically
> just use that.

But the internal pipe buffer uses dedicated pages, so there is
a minimum of one copy involved. Doesn't sendfile() do zero-copy
from a file's pages to a socket, if the socket's driver supports
it?

Also why isn't splice() just called cat()?

Two new system calls: splice() and sync_file_range()

axboe — 2006-04-04T15:02:55+00:00

sys_sendfile() can never go, as it's a part of the user space ABI. However, the internal implementation can be replaced with a call to splice() instead. The splice git branch has support for fd -> fd splicing now (by using a virtual pipe), so sys_sendfile can basically just use that.

Two new system calls: splice() and sync_file_range()

zlynx — 2006-04-04T14:13:05+00:00

I gathered from LKML that sendfile is going to become a call to splice. But sendfile will probably stay in the kernel for many versions to come for legacy support. Linus does try to keep ABI compatibility for user-space.

Two new system calls: splice() and sync_file_range()

andersg — 2006-04-04T11:26:44+00:00

Is splice going to deprecate sendfile(2)?

Two new system calls: splice() and sync_file_range()

TwoTimeGrime — 2006-04-03T23:44:39+00:00

Nevermind. I saw in http://lwn.net/Articles/164887/ that it described how splice works at the bottom of the article.

Two new system calls: splice() and sync_file_range()

TwoTimeGrime — 2006-04-03T23:40:26+00:00

Could someone please explain what the effect of splice() is supposed to be? Is it just a faster way for the kernel to move data from one place to another? Is this something that programs would use or would it be something that other parts of the kernel use? I see that it has fdin and fdout as arguments. Does that mean that it uses file descriptors and can be used for copying files? I don't know anything about kernel development so I'm trying to put this feature into context.

Thanks.