forcing merging of block requests on NVMe

2017-08-11 Thread Thanos Makatos
In my environment I have large, sequential I/O requests (e.g. 4 MB) split into much smaller requests (e.g. 8 KB) and passed to a kernel module, which in turn submits them to an NVMe device. This splitting of requests seems to hurt performance badly. Because of architectural reasons I cannot avoid

Re: [RFC PATCH] cfq: Give a chance for arming slice idle timer in case of group_idle

2017-08-11 Thread Jens Axboe
On 08/10/2017 11:15 PM, Ritesh Harjani wrote: > Hi Jens, > > Could you please take a look at below patch and the issue it is trying > to solve. Please let us know your thoughts on the below problem and the > patch. It looks reasonable to me. I'll queue it up for 4.14. -- Jens Axboe

Re: [PATCH BUGFIX/IMPROVEMENT V2 0/2] block, bfq: improve and refactor throughput-boosting logic

2017-08-11 Thread Jens Axboe
On 08/10/2017 01:55 PM, Paolo Valente wrote: > >> Il giorno 04 ago 2017, alle ore 07:35, Paolo Valente >> ha scritto: >> >> Hi, >> these two patches improve throughput-boosting logic in two >> aspects. The first patch refactors the parts of the device-idling >> logic,

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-11 Thread Christoph Hellwig
On Fri, Aug 11, 2017 at 03:49:29PM +0200, Benjamin Block wrote: > On Fri, Aug 11, 2017 at 11:14:15AM +0200, Christoph Hellwig wrote: > > But patch 1 still creates an additional copy of the sense data for > > all bsg users. > > > > Huh? What additional copy? There is one reply-buffer and that is

Re: [PATCH V2 00/20] blk-mq-sched: improve SCSI-MQ performance

2017-08-11 Thread James Bottomley
On Fri, 2017-08-11 at 01:11 -0700, Christoph Hellwig wrote: > [+ Martin and linux-scsi] > > Given that we need this big pile and a few bfq fixes to avoid > major regressesions I'm tempted to revert the default to scsi-mq > for 4.14, but bring it back a little later for 4.15. > > What do you

Re: [GIT PULL] nvme updates for 4.13-rc

2017-08-11 Thread Jens Axboe
On 08/11/2017 02:00 AM, Christoph Hellwig wrote: > A few more small fixes - the fc/lpfc update is the biggest by far. > > The following changes since commit 7dd1ab163c17e11473a65b11f7e748db30618ebb: > > nvme: validate admin queue before unquiesce (2017-07-26 17:41:41 +0200) > > are available

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-11 Thread Benjamin Block
On Fri, Aug 11, 2017 at 11:14:15AM +0200, Christoph Hellwig wrote: > But patch 1 still creates an additional copy of the sense data for > all bsg users. > Huh? What additional copy? There is one reply-buffer and that is copied into the user-buffer should it contain valid data. Just like in your

Re: [PATCH 4/5] RFC: mmc: block: Convert RPMB to a character device

2017-08-11 Thread Linus Walleij
On Mon, Jun 19, 2017 at 11:18 PM, Tomas Winkler wrote: > That's correct, I guess someone didn't read the spec till the end when > adding rpmb block device. > though also looks like that the software guys where drinking up in the > bar while jdec committee has met. :D >> +/*

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-11 Thread Christoph Hellwig
But patch 1 still creates an additional copy of the sense data for all bsg users. Can you test the patch below which implements my suggestion? Your other patches should still apply fine on top modulo minor context changes. --- >From 4cd32ee48e334b62b55bff0d380833b978454040 Mon Sep 17 00:00:00

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-11 Thread Christoph Hellwig
My point was that we now gurantee that that the sense data is not a stack pointer an a driver can DMA to it. Now for BSG the sense data is "just" abused as reply, but the point still stands - we don't want to pass a possible stack pointer to drivers in a data buffer because we want to allow DMA

Re: [PATCH V2 00/20] blk-mq-sched: improve SCSI-MQ performance

2017-08-11 Thread Christoph Hellwig
[+ Martin and linux-scsi] Given that we need this big pile and a few bfq fixes to avoid major regressesions I'm tempted to revert the default to scsi-mq for 4.14, but bring it back a little later for 4.15. What do you think? Maybe for 4.15 we could also do it through the block tree where all

[GIT PULL] nvme updates for 4.13-rc

2017-08-11 Thread Christoph Hellwig
A few more small fixes - the fc/lpfc update is the biggest by far. The following changes since commit 7dd1ab163c17e11473a65b11f7e748db30618ebb: nvme: validate admin queue before unquiesce (2017-07-26 17:41:41 +0200) are available in the git repository at: git://git.infradead.org/nvme.git