Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754070Ab3I0OjV (ORCPT ); Fri, 27 Sep 2013 10:39:21 -0400 Received: from mail-qc0-f181.google.com ([209.85.216.181]:42742 "EHLO mail-qc0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753734Ab3I0OjQ (ORCPT ); Fri, 27 Sep 2013 10:39:16 -0400 MIME-Version: 1.0 X-Originating-IP: [86.59.245.170] In-Reply-To: <52458F79.8040801@redhat.com> References: <1378919210-10372-1-git-send-email-zab@redhat.com> <20130925183828.GA30372@lenny.home.zabbo.net> <20130925190620.GB30372@lenny.home.zabbo.net> <20130925195526.GA18971@fieldses.org> <20130925210742.GG30372@lenny.home.zabbo.net> <20130926153359.GE704@fieldses.org> <20130926190611.GP30372@lenny.home.zabbo.net> <5244A5E7.90808@redhat.com> <52458F79.8040801@redhat.com> Date: Fri, 27 Sep 2013 16:39:15 +0200 Message-ID: Subject: Re: [RFC] extending splice for copy offloading From: Miklos Szeredi To: Ric Wheeler Cc: Zach Brown , "J. Bruce Fields" , Anna Schumaker , Kernel Mailing List , Linux-Fsdevel , "linux-nfs@vger.kernel.org" , Trond Myklebust , Bryan Schumaker , "Martin K. Petersen" , Jens Axboe , Mark Fasheh , Joel Becker , Eric Wong Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1749 Lines: 40 On Fri, Sep 27, 2013 at 4:00 PM, Ric Wheeler wrote: > I think that you are an order of magnitude off here in thinking about the > scale of the operations. > > An enabled, synchronize copy offload to an array (or one that turns into a > reflink locally) is effectively the cost of the call itself. Let's say no > slower than one IO to a S-ATA disk (10ms?) as a pessimistic guess. > Realistically, that call is much faster than that worst case number. > > Copying any substantial amount of data - like the target workload of VM > images or media files - would be hundreds of MB's per copy and that would > take seconds or minutes. Will a single splice-copy operation be interruptible/restartable? If not, how should apps size one request so that it doesn't take too much time? Even for slow devices (usb stick)? If it will be restartable, how? Can remote copy be done with this? Over a high latency network? Those are the questions I'm worried about. > > We should really work on getting the basic mechanism working and robust > without any complications, then we can look at real, measured performance > and see if there is any justification for adding complexity. Go for that. But don't forget that at the end of the day actual apps will need to be converted like file managers and "dd" and "cp" and we definitely don't wont a userspace library to be able to figure out how the copy is done most efficiently; it's something for the kernel to figure out. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/