On Thu, Sep 26, 2013 at 11:23 PM, Ric Wheeler <rwheeler@xxxxxxxxxx> wrote:On 09/26/2013 03:53 PM, Miklos Szeredi wrote:I meant buffering the COPY, not the data. Doing the COPYOn Thu, Sep 26, 2013 at 9:06 PM, Zach Brown <zab@xxxxxxxxxx> wrote:Buffering misses the whole point of the copy offload - the idea is *not* to
I think either buffering or async is needed to get good perforrmaceBut I'm not sure it's worth the effort; 99% of the use of thisAnd perhaps we don't. Perhaps we can provide this much simpler
interface will be copying whole files. And for that perhaps we need a
different API, one which has been discussed some time ago:
asynchronous copyfile() returns immediately with a pollable event
descriptor indicating copy progress, and some way to cancel the copy.
And that can internally rely on ->direct_splice(), with appropriate
algorithms for determine the optimal chunk size.
data-plane interface that works well enough for most everyone and can
avoid going down the async rat hole, yet again.
without too much complexity in the app (which is not good). Buffering
works quite well for regular I/O, so maybe its the way to go here as
well.
Thanks,
Miklos
read or write the actual data in the most interesting cases which offload
the operation to a smart target device or file system.
synchronously will always incur a performance penalty, the amount
depending on the latency, which can be significant with networking.
We think of write(2) as a synchronous interface, because that's the
appearance we get from all that hard work the page cache and delayed
writeback code does to make an asynchronous operation look as if it
was synchronous. So from a userspace API perspective a sync interface
is nice, but inside we almost always have async interfaces to do the
actual work.
Thanks,
Miklos