Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2956817pxu; Mon, 7 Dec 2020 22:47:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJztB/K6PtJ4rmixdynuqI6BydrfCVK9rWVOqFm9rXEcecAsnh6S2WR8Jsd8TuU0Tqa1En8m X-Received: by 2002:a17:906:4881:: with SMTP id v1mr21214930ejq.465.1607410079016; Mon, 07 Dec 2020 22:47:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607410079; cv=none; d=google.com; s=arc-20160816; b=vReMXpfXgSazmfYzS8Nbuyfx2JZpZDsnbEgHNwkFDHo7laqPEXNiJucOWP6zy8dZna /JNrwwEN+IwabAJQHr6w/E+G1PjEJ8Ge47sqMtUMIIUh9olHN6vhUPn16o1z13u3Ya96 AvOm6GWMBX9dlWuFYsc5+5Cxh57TQ8W1yoG5Ftj8QwEIYzvNod4z/ePc67IRrBIX0YJU JJa2p5wrFkWeTglLtiAgamqPLIm1UlrKLd/jwXYAKPgrDL/zAJBoILVA45dZsQptL24t 05VPUcxckoeSS5GvU/YcYXXu16EjuwDK/qVSue12JK5oY2AXzULD5QKDvNSm/z7r8BMO KnaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=oLshopQGy02OTQANPEfj1QvI73w9cnIJbRKnLgdGBVY=; b=DkP14MKDKSZqxQi1cfVEtXmpyuP+NLrmhHNFYWgZsnFwLE4v02AoHowaAeI6c1+l6n xS9KV5yvBXlvBqgIHOQ1e8aXuqeU8LKFtCk0bgVm6eJRAMJQca7t1OZo7/o0658+kpnC 1NAQS3z9M+CclJVQ4WlXBCPlw6NVwvUTKv/WXgTLpBfZBIzpUd+hNVBUIYimqquyEb2p rAlJE/UB/hdcrinnQwPIkOX4W4WYskKYFltRqDkzoyIgEo+xXqjH0lzJopV7ud9UfW9U xS6P07pQSNrbHiPUEMUYEKEBSA0xCRCtwzoUcgLataQXrxIm/MxjACOnp13T69XiL3p9 DhXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t27si7626846eje.510.2020.12.07.22.47.35; Mon, 07 Dec 2020 22:47:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726416AbgLHGpM (ORCPT + 99 others); Tue, 8 Dec 2020 01:45:12 -0500 Received: from mx2.suse.de ([195.135.220.15]:36662 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725881AbgLHGpM (ORCPT ); Tue, 8 Dec 2020 01:45:12 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D9B2FAB63; Tue, 8 Dec 2020 06:44:30 +0000 (UTC) Subject: Re: [RFC PATCH v2 0/2] add simple copy support To: dgilbert@interlog.com, Christoph Hellwig , SelvaKumar S Cc: linux-nvme@lists.infradead.org, kbusch@kernel.org, axboe@kernel.dk, damien.lemoal@wdc.com, sagi@grimberg.me, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com, snitzer@redhat.com, selvajove@gmail.com, nj.shetty@samsung.com, joshi.k@samsung.com, javier.gonz@samsung.com, "Martin K. Petersen" , Bart Van Assche , Mikulas Patocka , linux-scsi@vger.kernel.org References: <20201204094659.12732-1-selvakuma.s1@samsung.com> <20201207141123.GC31159@lst.de> <01fe46ac-16a5-d4db-f23d-07a03d3935f3@suse.de> <194d7813-8c8c-85c8-e0c8-94aaab7c291e@interlog.com> From: Hannes Reinecke Message-ID: <9b2f5ab2-3358-fcce-678f-982ef79c9252@suse.de> Date: Tue, 8 Dec 2020 07:44:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <194d7813-8c8c-85c8-e0c8-94aaab7c291e@interlog.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/7/20 11:12 PM, Douglas Gilbert wrote: > On 2020-12-07 9:56 a.m., Hannes Reinecke wrote: >> On 12/7/20 3:11 PM, Christoph Hellwig wrote: >>> So, I'm really worried about: >>> >>>   a) a good use case.  GC in f2fs or btrfs seem like good use cases, as >>>      does accelating dm-kcopyd.  I agree with Damien that lifting >>> dm-kcopyd >>>      to common code would also be really nice.  I'm not 100% sure it >>> should >>>      be a requirement, but it sure would be nice to have >>>      I don't think just adding an ioctl is enough of a use case for >>> complex >>>      kernel infrastructure. >>>   b) We had a bunch of different attempts at SCSI XCOPY support form >>> IIRC >>>      Martin, Bart and Mikulas.  I think we need to pull them into this >>>      discussion, and make sure whatever we do covers the SCSI needs. >>> >> And we shouldn't forget that the main issue which killed all previous >> implementations was a missing QoS guarantee. >> It's nice to have simply copy, but if the implementation is _slower_ >> than doing it by hand from the OS there is very little point in even >> attempting to do so. >> I can't see any provisions for that in the TPAR, leading me to the >> assumption that NVMe simple copy will suffer from the same issue. >> >> So if we can't address this I guess this attempt will fail, too. > > I have been doing quite a lot of work and testing in my sg driver rewrite > in the copy and compare area. The baselines for performance are dd and > io_uring-cp (in liburing). There are lots of ways to improve on them. Here > are some: >    - the user data need never pass through the user space (could >      mmap it out during the READ if there is a good reason). Only the >      metadata (e.g. NVMe or SCSI commands) needs to come from the user >      space and errors, if any, reported back to the user space. >    - break a large copy (or compare) into segments, with each segment >      a "comfortable" size for the OS to handle, say 256 KB >    - there is one constraint: the READ in each segment must complete >      before its paired WRITE can commence >      - extra constraint for some zoned disks: WRITEs must be >        issued in order (assuming they are applied in that order, if >        not, need to wait until each WRITE completes) >    - arrange for READ WRITE pair in each segment to share the same bio >    - have multiple slots each holding a segment (i.e. a bio and >      metadata to process a READ-WRITE pair) >    - re-use each slot's bio for the following READ-WRITE pair >    - issue the READs in each slot asynchronously and do an interleaved >      (io)poll for completion. Then issue the paired WRITE >      asynchronously >    - the above "slot" algorithm runs in one thread, so there can be >      multiple threads doing the same algorithm. Segment manager needs >      to be locked (or use an atomics) so that each segment (identified >      by its starting LBAs) is issued once and only once when the >      next thread wants a segment to copy > > Running multiple threads gives diminishing or even worsening returns. > Runtime metrics on lock contention and storage bus capacity may help > choosing the number of threads. A simpler approach might be add more > threads until the combined throughput increase is less than 10% say. > > > The 'compare' that I mention is based on the SCSI VERIFY(BYTCHK=1) command > (or NVMe NVM Compare command). Using dd logic, a disk to disk compare can > be implemented with not much more work than changing the WRITE to a VERIFY > command. This is a different approach to the Linux cmp utility which > READs in both sides and does a memcmp() type operation. Using ramdisks > (from the scsi_debug driver) the compare operation (max ~ 10 GB/s) was > actually faster than the copy (max ~ 7 GB/s). I put this down to WRITE > operations taking a write lock over the store while the VERIFY only > needs a read lock so many VERIFY operations can co-exist on the same > store. Unfortunately on real SAS and NVMe SSDs that I tested the > performance of the VERIFY and NVM Compare commands is underwhelming. > For comparison, using scsi_debug ramdisks, dd copy throughput was > < 1 GB/s and io_uring-cp was around 2-3 GB/s. The system was Ryzen > 3600 based. > Which is precisely my concern. Simple copy might be efficient for one particular implementation, but it might be completely off the board for others. But both will be claiming to support it, and us having no idea whether choosing simple copy will speed up matters or not. Without having a programmatic way to figure out the speed of the implementation we have to detect the performance ourselves, like the benchmarking loop RAID5 does. I was hoping to avoid that, and just ask the device/controller; but that turned out to be in vain. Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer