Re: [PATCH] blk-mq-debugfs: Also show requests that have not yet been started

2018-10-04 Thread Hannes Reinecke 

On 10/4/18 7:35 PM, Bart Van Assche wrote:

When debugging e.g. the SCSI timeout handler it is important that
requests that have not yet been started or that already have
completed are also reported through debugfs.

Signed-off-by: Bart Van Assche 
Cc: Christoph Hellwig 
Cc: Ming Lei 
Cc: Hannes Reinecke 
Cc: Johannes Thumshirn 
Cc: Martin K. Petersen 
---
  block/blk-mq-debugfs.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
index a5ea86835fcb..41b86f50d126 100644
--- a/block/blk-mq-debugfs.c
+++ b/block/blk-mq-debugfs.c
@@ -431,8 +431,7 @@ static void hctx_show_busy_rq(struct request *rq, void 
*data, bool reserved)
  {
const struct show_busy_params *params = data;
  
-	if (blk_mq_map_queue(rq->q, rq->mq_ctx->cpu) == params->hctx &&

-   blk_mq_rq_state(rq) != MQ_RQ_IDLE)
+   if (blk_mq_map_queue(rq->q, rq->mq_ctx->cpu) == params->hctx)
__blk_mq_debugfs_rq_show(params->m,
 list_entry_rq(>queuelist));
  }


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[PATCH] lightnvm: consider max hw sectors supported for max_write_pgs

2018-10-04 Thread Zhoujie Wu 
When do GC, the number of read/write sectors are determined
by max_write_pgs(see gc_rq preparation in pblk_gc_line_prepare_ws).

Due to max_write_pgs doesn't consider max hw sectors
supported by nvme controller(128K), which leads to GC
tries to read 64 * 4K in one command, and see below error
caused by pblk_bio_map_addr in function pblk_submit_read_gc.

[ 2923.005376] pblk: could not add page to bio
[ 2923.005377] pblk: could not allocate GC bio (18446744073709551604)

Signed-off-by: Zhoujie Wu 
---
 drivers/lightnvm/pblk-init.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
index e357388..2e51875 100644
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -393,6 +393,7 @@ static int pblk_core_init(struct pblk *pblk)
struct nvm_tgt_dev *dev = pblk->dev;
struct nvm_geo *geo = >geo;
int ret, max_write_ppas;
+   struct request_queue *bqueue = dev->q;
 
atomic64_set(>user_wa, 0);
atomic64_set(>pad_wa, 0);
@@ -407,6 +408,9 @@ static int pblk_core_init(struct pblk *pblk)
pblk->min_write_pgs = geo->ws_opt;
max_write_ppas = pblk->min_write_pgs * geo->all_luns;
pblk->max_write_pgs = min_t(int, max_write_ppas, NVM_MAX_VLBA);
+   /* consider the max hw sector as well */
+   pblk->max_write_pgs =  min_t(int, pblk->max_write_pgs,
+   queue_max_hw_sectors(bqueue) / (geo->csecs >> 9));
pblk_set_sec_per_write(pblk, pblk->min_write_pgs);
 
pblk->pad_dist = kcalloc(pblk->min_write_pgs - 1, sizeof(atomic64_t),
-- 
1.9.1

[PATCH] blk-mq-debugfs: Also show requests that have not yet been started

2018-10-04 Thread Bart Van Assche 
When debugging e.g. the SCSI timeout handler it is important that
requests that have not yet been started or that already have
completed are also reported through debugfs.

Signed-off-by: Bart Van Assche 
Cc: Christoph Hellwig 
Cc: Ming Lei 
Cc: Hannes Reinecke 
Cc: Johannes Thumshirn 
Cc: Martin K. Petersen 
---
 block/blk-mq-debugfs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
index a5ea86835fcb..41b86f50d126 100644
--- a/block/blk-mq-debugfs.c
+++ b/block/blk-mq-debugfs.c
@@ -431,8 +431,7 @@ static void hctx_show_busy_rq(struct request *rq, void 
*data, bool reserved)
 {
const struct show_busy_params *params = data;
 
-   if (blk_mq_map_queue(rq->q, rq->mq_ctx->cpu) == params->hctx &&
-   blk_mq_rq_state(rq) != MQ_RQ_IDLE)
+   if (blk_mq_map_queue(rq->q, rq->mq_ctx->cpu) == params->hctx)
__blk_mq_debugfs_rq_show(params->m,
 list_entry_rq(>queuelist));
 }
-- 
2.19.0.605.g01d371f741-goog

Re: Why BFQ scheduler available only for NVMe device?

2018-10-04 Thread Jens Axboe 
On 10/4/18 10:15 AM, Mikhail Gavrilov wrote:
> Sorry I don't finded answer on my question.
> Why BFQ scheduler available only for NVMe device?
> 
> $ find /sys -name scheduler -exec grep . {} +
> find: ‘/sys/kernel/debug’: Permission denied
> find: ‘/sys/fs/pstore’: Permission denied
> find: ‘/sys/fs/bpf’: Permission denied
> /sys/devices/pci:00/:00:01.3/:02:00.1/ata5/host4/target4:0:0/4:0:0:0/block/sda/queue/scheduler:noop
> deadline [cfq]
> /sys/devices/pci:00/:00:01.1/:01:00.0/nvme/nvme0/nvme0n1/queue/scheduler:[none]
> mq-deadline bfq
> /sys/devices/pci:00/:00:07.1/:0c:00.3/usb4/4-3/4-3.4/4-3.4.1/4-3.4.1:1.0/host9/target9:0:0/9:0:0:0/block/sdb/queue/scheduler:noop
> deadline [cfq]

It isn't, but it's only available for MQ devices. For SCSI, you want to
set:

CONFIG_SCSI_MQ_DEFAULT=y

and if that isn't feasible due to running a distro build, then you want
to add scsi_mod.use_blk_mq=1 to your boot parameters.

-- 
Jens Axboe

Why BFQ scheduler available only for NVMe device?

2018-10-04 Thread Mikhail Gavrilov 
Sorry I don't finded answer on my question.
Why BFQ scheduler available only for NVMe device?

$ find /sys -name scheduler -exec grep . {} +
find: ‘/sys/kernel/debug’: Permission denied
find: ‘/sys/fs/pstore’: Permission denied
find: ‘/sys/fs/bpf’: Permission denied
/sys/devices/pci:00/:00:01.3/:02:00.1/ata5/host4/target4:0:0/4:0:0:0/block/sda/queue/scheduler:noop
deadline [cfq]
/sys/devices/pci:00/:00:01.1/:01:00.0/nvme/nvme0/nvme0n1/queue/scheduler:[none]
mq-deadline bfq
/sys/devices/pci:00/:00:07.1/:0c:00.3/usb4/4-3/4-3.4/4-3.4.1/4-3.4.1:1.0/host9/target9:0:0/9:0:0:0/block/sdb/queue/scheduler:noop
deadline [cfq]

$ uname -r
4.19.0-0.rc5.git3.1.fc30.x86_64

$ cat /boot/config-`uname -r` | grep -i bfq
CONFIG_IOSCHED_BFQ=m
CONFIG_BFQ_GROUP_IOSCHED=y


--
Best Regards,
Mike Gavrilov.

Re: [PATCH 0/14] loop: Fix oops and possible deadlocks

2018-10-04 Thread Jan Kara 
On Thu 27-09-18 23:47:01, Tetsuo Handa wrote:
> Possible changes folded into this series.

Thanks for having a look. But please comment on individual patches at
appropriate places instead of sending this patch where everything is just
mixed together. It is much easier to find out what we are talking about
that way.

>   (1) (I guess) no need to use _nested version.

I just preserved the current status as I didn't want to dig into that hole.
Even if you're right, that would be a separate change. Not something these
patches should deal with.

>   (2) Use mutex_lock_killable() where possible.

Where exactly? I've only noticed you've changed loop_probe() where I think
the change is just bogus. That gets called on device insertion and you have
nowhere to deliver the signal in that case.

>   (3) Move fput() to after mutex_unlock().

Again, independent change. I've just preserved the current situation. But
probably worth including in this series as a separate patch. Care to send a
follow up patch with proper changelog etc.?

>   (4) Don't return 0 upon invalid loop_control_ioctl().

Good catch, I'll fix that up.

>   (5) No need to mutex_lock()/mutex_unlock() on each loop device at
>   unregister_transfer_cb() callback.

Another independent optimization. Will you send a follow up patch? I can
write the patch (and the one above) but I don't want to steal the credit
from you...

>   (6) No need to mutex_unlock()+mutex_lock() when calling __loop_clr_fd().

This is deliberate so that we get rid of the weird "__loop_clr_fd()
releases mutex it did not acquire". This is not performance critical path
by any means so better keep the locking simple.

Honza
-- 
Jan Kara 
SUSE Labs, CR