Re: [dm-devel] [PATCH 05/16] dm: always defer request allocation to the owner of the request_queue

On Tue, Jan 24, 2017 at 11:39:51AM -0500, Mike Snitzer wrote: > Fair enough. Cc'ing Junichi just in case he sees anything we're > missing. Thanks, I'll wait for his repsonse before reposting with the few accumulated changes (including the dm cleanup). -- dm-devel mailing list

Re: [dm-devel] [PATCH 05/16] dm: always defer request allocation to the owner of the request_queue

On Tue, Jan 24 2017 at 9:20am -0500, Christoph Hellwig wrote: > On Tue, Jan 24, 2017 at 05:05:39AM -0500, Mike Snitzer wrote: > > possible and is welcomed cleanup. The only concern I have is that using > > get_request() for the old request_fn request_queue eliminates the > >

Re: [dm-devel] [PATCH 15/16] block: split scsi_request out of struct request

On Tue, 2017-01-24 at 09:09 +0100, h...@lst.de wrote: > On Tue, Jan 24, 2017 at 12:33:13AM +, Bart Van Assche wrote: > > Do we perhaps need a check before the above memcpy() call whether or not > > sense == NULL? > > Yes, probably. I didn't think of the case where the caller wouldn't > pass

Re: [dm-devel] [PATCH 01/16] block: fix elevator init check

On Tue, Jan 24, 2017 at 08:06:39AM -0700, Jens Axboe wrote: > We check for REQ_PREFLUSH | REQ_FUA in so many places though, might not > be a bad idea to keep the helper but just make it take the opf and fix > up the other locations too. The fact that PREFLUSH|FUA is the magic to > check for is

Re: [dm-devel] [PATCH 01/16] block: fix elevator init check

On Mon, Jan 23 2017, Christoph Hellwig wrote: > We can't initalize the elevator fields for flushes as flush share space > in struct request with the elevator data. But currently we can't > commnicate that a request is a flush through blk_get_request as we > can only pass READ or WRITE, and the

[dm-devel] [PATCH] dm: switch dm-verity to async hash crypto API

Use of the synchronous digest API limits dm-verity when using pure CPU based algorithm providers and rules out the use of most off CPU algorithm providers which are normally asynchronous by nature, which can speed up performance even further. This reduced performance is especially expressed

Re: [dm-devel] [PATCH 05/16] dm: always defer request allocation to the owner of the request_queue

On Tue, Jan 24, 2017 at 05:05:39AM -0500, Mike Snitzer wrote: > possible and is welcomed cleanup. The only concern I have is that using > get_request() for the old request_fn request_queue eliminates the > guaranteed availability of requests to allow for forward progress (on > path failure or for

Re: [dm-devel] [PATCH 16/16] block: don't assign cmd_flags in __blk_rq_prep_clone

On 01/23/2017 04:29 PM, Christoph Hellwig wrote: > These days we have the proper flags set since request allocation time. > > Signed-off-by: Christoph Hellwig > --- > block/blk-core.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/block/blk-core.c b/block/blk-core.c >

Re: [dm-devel] [PATCH 15/16] block: split scsi_request out of struct request

On 01/23/2017 04:29 PM, Christoph Hellwig wrote: > And require all drivers that want to support BLOCK_PC to allocate it > as the first thing of their private data. To support this the legacy > IDE and BSG code is switched to set cmd_size on their queues to let > the block layer allocate the

Re: [dm-devel] [PATCH 13/16] scsi: allocate scsi_cmnd structures as part of struct request

On 01/23/2017 04:29 PM, Christoph Hellwig wrote: > Rely on the new block layer functionality to allocate additional driver > specific data behind struct request instead of implementing it in SCSI > itѕelf. > > Signed-off-by: Christoph Hellwig > --- > drivers/scsi/hosts.c | 20

Re: [dm-devel] [PATCH 09/16] scsi: remove gfp_flags member in scsi_host_cmd_pool

On Mon, Jan 23, 2017 at 04:29:14PM +0100, Christoph Hellwig wrote: > When using the slab allocator we already decide at cache creation time if > an allocation comes from a GFP_DMA pool using the SLAB_CACHE_DMA flag, > and there is no point passing the kmalloc-family only GFP_DMA flag to >

Re: [dm-devel] [PATCH 12/16] scsi: remove __scsi_alloc_queue

On Mon, Jan 23, 2017 at 04:29:17PM +0100, Christoph Hellwig wrote: > Instead do an internal export of __scsi_init_queue for the transport > classes that export BSG nodes. > > Signed-off-by: Christoph Hellwig > --- Looks good, Reviewed-by: Johannes Thumshirn --

Re: [dm-devel] [PATCH 10/16] scsi: respect unchecked_isa_dma for blk-mq

On 01/23/2017 04:29 PM, Christoph Hellwig wrote: > Currently blk-mq always allocates the sense buffer using normal GFP_KERNEL > allocation. Refactor the cmd pool code to split the cmd and sense allocation > and share the code to allocate the sense buffers as well as the sense buffer > slab caches

Re: [dm-devel] [PATCH 11/16] scsi: remove scsi_cmd_dma_pool

On 01/23/2017 04:29 PM, Christoph Hellwig wrote: > There is no need for GFP_DMA allocations of the scsi_cmnd structures > themselves, all that might be DMAed to or from is the actual payload, > or the sense buffers. > > Signed-off-by: Christoph Hellwig > --- > drivers/scsi/scsi.c |

Re: [dm-devel] [PATCH 05/16] dm: always defer request allocation to the owner of the request_queue

On Mon, Jan 23 2017 at 10:29am -0500, Christoph Hellwig wrote: > DM already calls blk_mq_alloc_request on the request_queue of the > underlying device if it is a blk-mq device. But now that we allow drivers > to allocate additional data and initialize it ahead of time we need to do

Re: [dm-devel] [PATCH 05/16] dm: always defer request allocation to the owner of the request_queue

On 01/23/2017 04:29 PM, Christoph Hellwig wrote: > DM already calls blk_mq_alloc_request on the request_queue of the > underlying device if it is a blk-mq device. But now that we allow drivers > to allocate additional data and initialize it ahead of time we need to do > the same for all drivers.

Re: [dm-devel] [PATCH 04/16] dm: remove incomple BLOCK_PC support

On 01/23/2017 04:29 PM, Christoph Hellwig wrote: > DM tries to copy a few fields around for BLOCK_PC requests, but given > that no dm-target ever wires up scsi_cmd_ioctl BLOCK_PC can't actually > be sent to dm. > > Signed-off-by: Christoph Hellwig > --- > drivers/md/dm-rq.c | 16

Re: [dm-devel] [PATCH 03/16] block: allow specifying size for extra command data

On 01/23/2017 04:29 PM, Christoph Hellwig wrote: > This mirrors the blk-mq capabilities to allocate extra drivers-specific > data behind struct request by setting a cmd_size field, as well as having > a constructor / destructor for it. > > Signed-off-by: Christoph Hellwig > --- >