Thread (46 messages) 46 messages, 6 authors, 2017-04-28

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

From: Jason Gunthorpe <hidden>
Date: 2017-04-27 22:12:06
Also in: dm-devel, dri-devel, intel-gfx, linux-crypto, linux-media, linux-mmc, linux-rdma, linux-scsi, lkml, netdev, nvdimm

On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
On 27/04/17 02:53 PM, Jason Gunthorpe wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help