From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A249EB64DC for ; Thu, 20 Jul 2023 07:50:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231739AbjGTHu5 (ORCPT ); Thu, 20 Jul 2023 03:50:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231336AbjGTHu5 (ORCPT ); Thu, 20 Jul 2023 03:50:57 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1BB12128; Thu, 20 Jul 2023 00:50:55 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 7C7756732D; Thu, 20 Jul 2023 09:50:50 +0200 (CEST) Date: Thu, 20 Jul 2023 09:50:50 +0200 From: Christoph Hellwig To: Nitesh Shetty Cc: Jens Axboe , Jonathan Corbet , Alasdair Kergon , Mike Snitzer , dm-devel@redhat.com, Keith Busch , Christoph Hellwig , Sagi Grimberg , Chaitanya Kulkarni , Alexander Viro , Christian Brauner , martin.petersen@oracle.com, linux-scsi@vger.kernel.org, willy@infradead.org, hare@suse.de, djwong@kernel.org, bvanassche@acm.org, ming.lei@redhat.com, dlemoal@kernel.org, nitheshshetty@gmail.com, gost.dev@samsung.com, Vincent Fu , Anuj Gupta , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v13 3/9] block: add emulation for copy Message-ID: <20230720075050.GB5042@lst.de> References: <20230627183629.26571-1-nj.shetty@samsung.com> <20230627183629.26571-4-nj.shetty@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230627183629.26571-4-nj.shetty@samsung.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org > +static void *blkdev_copy_alloc_buf(sector_t req_size, sector_t *alloc_size, > + gfp_t gfp_mask) > +{ > + int min_size = PAGE_SIZE; > + void *buf; > + > + while (req_size >= min_size) { > + buf = kvmalloc(req_size, gfp_mask); > + if (buf) { > + *alloc_size = req_size; > + return buf; > + } > + /* retry half the requested size */ > + req_size >>= 1; > + } > + > + return NULL; Is there any good reason for using vmalloc instead of a bunch of distcontiguous pages? > + ctx = kzalloc(sizeof(struct copy_ctx), gfp_mask); > + if (!ctx) > + goto err_ctx; I'd suspect it would be better to just allocte a single buffer and only have a single outstanding copy. That will reduce the bandwith you can theoretically get, but copies tend to be background operations anyway. It will reduce the required memory, and thus the chance for this operation to fail on a loaded system. It will also dramatically reduce the effect on memory managment. > + read_bio = bio_map_kern(in, buf, buf_len, gfp_mask); > + if (IS_ERR(read_bio)) > + goto err_read_bio; > + > + write_bio = bio_map_kern(out, buf, buf_len, gfp_mask); > + if (IS_ERR(write_bio)) > + goto err_write_bio; bio_map_kern is only for passthrough I/Os. You need to use a bio_add_page loop here. > index 336146798e56..f8c80940c7ad 100644 > --- a/include/linux/blk_types.h > +++ b/include/linux/blk_types.h > @@ -562,4 +562,9 @@ struct cio { > atomic_t refcount; > }; > > +struct copy_ctx { > + struct cio *cio; > + struct work_struct dispatch_work; > + struct bio *write_bio; > +}; This is misnamed as it's only used by the fallback code, and also should be private to blk-lib.c.