[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170427221132.GA30036@obsidianresearch.com>
Date: Thu, 27 Apr 2017 16:11:32 -0600
From: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To: Logan Gunthorpe <logang@...tatee.com>
Cc: Roger Pau Monné <roger.pau@...rix.com>,
linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
intel-gfx@...ts.freedesktop.org, linux-raid@...r.kernel.org,
linux-mmc@...r.kernel.org, linux-nvdimm@...1.01.org,
linux-scsi@...r.kernel.org, open-iscsi@...glegroups.com,
megaraidlinux.pdl@...adcom.com, sparmaintainer@...sys.com,
devel@...verdev.osuosl.org, target-devel@...r.kernel.org,
netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
dm-devel@...hat.com, Christoph Hellwig <hch@....de>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
"James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
Jens Axboe <axboe@...nel.dk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dan Williams <dan.j.williams@...el.com>,
Ross Zwisler <ross.zwisler@...ux.intel.com>,
Matthew Wilcox <mawilcox@...rosoft.com>,
Sumit Semwal <sumit.semwal@...aro.org>,
Stephen Bates <sbates@...thlin.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Julien Grall <julien.grall@....com>
Subject: Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper
function
On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> On 27/04/17 02:53 PM, Jason Gunthorpe wrote:
> > blkfront is one of the drivers I looked at, and it appears to only be
> > memcpying with the bvec_data pointer, so I wonder why it does not use
> > sg_copy_X_buffer instead..
>
> But you'd potentially end up calling sg_copy_to_buffer multiple times
> per page within the sg (given that gnttab_foreach_grant_in_range might
> call blkif_copy_from_grant/blkif_setup_rw_req_grant multiple times).
> Even calling sg_copy_to_buffer once per page seems rather inefficient as
> it uses sg_miter internally.
Well, that is in the current form, with more users it would make sense
to optimize for the single page case, eg by providing the existing
call, providing a faster single-page-only variant of the copy, perhaps
even one that is inlined.
> Switching the for_each_sg to sg_miter is probably the nicer solution as
> it takes care of the mapping and the offset/length accounting for you
> and will have similar performance.
sg_miter will still fail when the sg contains __iomem, however I would
expect that the sg_copy will work with iomem, by using the __iomem
memcpy variant.
So, sg_copy should always be preferred in this new world with mixed
__iomem since it is the only primitive that can transparently handle
it.
Jason
Powered by blists - more mailing lists