how to enlarge value of max_sectors_kb

From: Tang Junhui There is a machine with very little max_sectors_kb size: [root@ceph151 queue]# pwd /sys/block/sdd/queue [root@ceph151 queue]# cat max_hw_sectors_kb 256 [root@ceph151 queue]# cat max_sectors_kb 256 The performance is very low when I run big I/Os. I can

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, Jan 12 2018 at 8:00pm -0500, Bart Van Assche wrote: > On Fri, 2018-01-12 at 19:52 -0500, Mike Snitzer wrote: > > It was 50 ms before it was 100 ms. No real explaination for these > > values other than they seem to make Bart's IB SRP testbed happy? > > But that

Re: [PATCH V3 2/5] dm-mpath: return DM_MAPIO_REQUEUE in case of rq allocation failure

On Fri, Jan 12, 2018 at 07:04:28PM +, Bart Van Assche wrote: > On Thu, 2018-01-11 at 14:01 +0800, Ming Lei wrote: > > diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c > > index 86bf502a8e51..fcddf5a62581 100644 > > --- a/drivers/md/dm-mpath.c > > +++ b/drivers/md/dm-mpath.c > > @@

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, 2018-01-12 at 19:52 -0500, Mike Snitzer wrote: > It was 50 ms before it was 100 ms. No real explaination for these > values other than they seem to make Bart's IB SRP testbed happy? But that constant was not introduced by me in the dm code. See e.g. the following commits: commit

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, Jan 12 2018 at 2:53pm -0500, Elliott, Robert (Persistent Memory) wrote: > > > > -Original Message- > > From: linux-block-ow...@vger.kernel.org [mailto:linux-block- > > ow...@vger.kernel.org] On Behalf Of Bart Van Assche > ... > > The intention of commit

Re: [Drbd-dev] [PATCH 23/27] drbd: make intelligent use of blkdev_issue_zeroout

Hello All, We just noticed that discards to DRBD devices backed by dm-thin devices are fully allocating the thin blocks. This behavior does not exist before ee472d83 block: add a flags argument to (__)blkdev_issue_zeroout The problem exists somewhere between [working] c20cfc27 block: stop

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, Jan 12 2018 at 6:42pm -0500, Bart Van Assche wrote: > On Fri, 2018-01-12 at 18:17 -0500, Mike Snitzer wrote: > > @@ -1570,7 +1570,10 @@ static int multipath_end_io(struct dm_target *ti, > > struct request *clone, > > if (error && blk_path_error(error)) { > >

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, 2018-01-12 at 18:17 -0500, Mike Snitzer wrote: > @@ -1570,7 +1570,10 @@ static int multipath_end_io(struct dm_target *ti, > struct request *clone, > if (error && blk_path_error(error)) { > struct multipath *m = ti->private; > > - r = DM_ENDIO_REQUEUE; > +

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, Jan 12 2018 at 1:54pm -0500, Bart Van Assche wrote: > The intention of commit 6077c2d706097c0 was to address the last mentioned > case. It may be possible to move the delayed queue rerun from the > dm_queue_rq() into dm_requeue_original_request(). But I think it

Re: [PATCH v2 3/4] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device

On Thu, 2018-01-11 at 10:23 +0800, Ming Lei wrote: > > not sufficient to prevent .queuecommand() calls from scsi_send_eh_cmnd(). > > Given it is error handling, do we need to prevent the .queuecommand() call > in scsi_send_eh_cmnd()? Could you share us what the actual issue > observed is from

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, Jan 12 2018 at 1:54pm -0500, Bart Van Assche wrote: > On Fri, 2018-01-12 at 13:06 -0500, Mike Snitzer wrote: > > OK, you have the stage: please give me a pointer to your best > > explaination of the several. > > Since the previous discussion about this topic

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

On Fri, 2018-01-12 at 15:05 -0700, Jens Axboe wrote: > On 1/12/18 3:00 PM, Bart Van Assche wrote: > > On Fri, 2018-01-12 at 14:55 -0700, Jens Axboe wrote: > > > On 1/12/18 2:52 PM, Bart Van Assche wrote: > > > > When debugging e.g. the SCSI timeout handler it is important that > > > > requests

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

On 1/12/18 3:00 PM, Bart Van Assche wrote: > On Fri, 2018-01-12 at 14:55 -0700, Jens Axboe wrote: >> On 1/12/18 2:52 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

Re: [PATCHSET v5] blk-mq: reimplement timeout handling

On 1/12/18 2:19 PM, Bart Van Assche wrote: > On Fri, 2018-01-12 at 14:07 -0700, Jens Axboe wrote: >> You're really not making it easy for folks to run this :-) > > My hope is that the ib_srp and ib_srpt patches will be accepted upstream soon. > As long as these are not upstream, anyone who wants

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

On 1/12/18 2:52 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. > > This patch depends on a patch that went upstream recently, namely >

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

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. This patch depends on a patch that went upstream recently, namely commit 14e3062fb185 ("scsi: core: Fix a scsi_show_rq() NULL

Re: [PATCHSET v5] blk-mq: reimplement timeout handling

On Fri, 2018-01-12 at 14:07 -0700, Jens Axboe wrote: > You're really not making it easy for folks to run this :-) My hope is that the ib_srp and ib_srpt patches will be accepted upstream soon. As long as these are not upstream, anyone who wants to retrieve these patches is welcome to clone

Re: [PATCHSET v5] blk-mq: reimplement timeout handling

On 1/12/18 1:57 PM, Bart Van Assche wrote: > On Tue, 2018-01-09 at 08:29 -0800, Tejun Heo wrote: >> Currently, blk-mq timeout path synchronizes against the usual >> issue/completion path using a complex scheme involving atomic >> bitflags, REQ_ATOM_*, memory barriers and subtle memory coherence >>

Re: [PATCHSET v5] blk-mq: reimplement timeout handling

On Tue, 2018-01-09 at 08:29 -0800, Tejun Heo wrote: > Currently, blk-mq timeout path synchronizes against the usual > issue/completion path using a complex scheme involving atomic > bitflags, REQ_ATOM_*, memory barriers and subtle memory coherence > rules. Unfortunatley, it contains quite a few

RE: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

> -Original Message- > From: linux-block-ow...@vger.kernel.org [mailto:linux-block- > ow...@vger.kernel.org] On Behalf Of Bart Van Assche ... > The intention of commit 6077c2d706097c0 was to address the last mentioned > case. It may be possible to move the delayed queue rerun from the >

Re: [PATCH 1/2] genirq/affinity: assign vectors to all possible CPUs

On Fri, 12 Jan 2018, Ming Lei wrote: > From: Christoph Hellwig > > Currently we assign managed interrupt vectors to all present CPUs. This > works fine for systems were we only online/offline CPUs. But in case of > systems that support physical CPU hotplug (or the virtualized

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, Jan 12 2018 at 1:54pm -0500, Bart Van Assche wrote: > On Fri, 2018-01-12 at 13:06 -0500, Mike Snitzer wrote: > > OK, you have the stage: please give me a pointer to your best > > explaination of the several. > > Since the previous discussion about this topic

Re: [PATCH V3 2/5] dm-mpath: return DM_MAPIO_REQUEUE in case of rq allocation failure

On Thu, 2018-01-11 at 14:01 +0800, Ming Lei wrote: > diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c > index 86bf502a8e51..fcddf5a62581 100644 > --- a/drivers/md/dm-mpath.c > +++ b/drivers/md/dm-mpath.c > @@ -533,8 +533,20 @@ static int multipath_clone_and_map(struct dm_target *ti, >

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, 2018-01-12 at 13:06 -0500, Mike Snitzer wrote: > OK, you have the stage: please give me a pointer to your best > explaination of the several. Since the previous discussion about this topic occurred more than a month ago it could take more time to look up an explanation than to explain it

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, Jan 12 2018 at 12:46pm -0500, Bart Van Assche wrote: > On Fri, 2018-01-12 at 12:40 -0500, Mike Snitzer wrote: > > You've not explained it many times. > > That's not correct. I have already several times posted a detailed and easy > to understand explanation OK,

Re: [PATCH 0/2] blk-mq: support physical CPU hotplug

On 1/11/18 7:53 PM, Ming Lei wrote: > Hi, > > This two patches support physical CPU hotplug, so that we can make blk-mq > scale well when new physical CPU is added or removed, and this use case > is normal for VM world. > > Also this patchset fixes the following warning reported by Christian >

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, 2018-01-12 at 12:40 -0500, Mike Snitzer wrote: > You've not explained it many times. That's not correct. I have already several times posted a detailed and easy to understand explanation > We cannot get a straight answer from you. That is a gross and incorrect statement. Please calm

Re: [GIT PULL] one nvme fix for Linux 4.15

On 1/12/18 8:09 AM, Christoph Hellwig wrote: > The following changes since commit 254beb84faccbe2f4eda0b51924857bdfb679969: > > nvme-fcloop: avoid possible uninitialized variable warning (2017-12-29 > 10:37:21 +0100) > > are available in the git repository at: > >

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, Jan 12 2018 at 12:26pm -0500, Bart Van Assche wrote: > On Fri, 2018-01-12 at 12:18 -0500, Mike Snitzer wrote: > > This is going upstream for 4.16: > >

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Fri, 2018-01-12 at 12:18 -0500, Mike Snitzer wrote: > This is going upstream for 4.16: > https://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git/commit/?h=dm-4.16=5b18cff4baedde77e0d69bd62a13ae78f9488d89 That is really gross. I have explained many times in detail on the dm-devel list

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Thu, Jan 11 2018 at 10:33pm -0500, Ming Lei wrote: > On Thu, Jan 11, 2018 at 08:57:21PM -0500, Mike Snitzer wrote: > > On Thu, Jan 11 2018 at 8:42pm -0500, > > Ming Lei wrote: > > > > > On Thu, Jan 11, 2018 at 10:37:37PM +, Bart Van Assche

[for-4.16 PATCH v6 2/4] block: properly protect the 'queue' kobj in blk_unregister_queue

The original commit e9a823fb34a8b (block: fix warning when I/O elevator is changed as request_queue is being removed) is pretty conflated. "conflated" because the resource being protected by q->sysfs_lock isn't the queue_flags (it is the 'queue' kobj). q->sysfs_lock serializes __elevator_change()

Re: [for-4.16 PATCH v5 2/4] block: properly protect the 'queue' kobj in blk_unregister_queue

On Fri, Jan 12 2018 at 10:17am -0500, Ming Lei wrote: > On Fri, Jan 12, 2018 at 10:06:04AM -0500, Mike Snitzer wrote: > > The original commit e9a823fb34a8b (block: fix warning when I/O elevator > > is changed as request_queue is being removed) is pretty conflated. > >

Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000436

> Il giorno 12 gen 2018, alle ore 09:29, Paolo Valente > ha scritto: > > > >> Il giorno 12 gen 2018, alle ore 05:18, Ming Lei ha >> scritto: >> >> On Thu, Jan 11, 2018 at 08:40:54AM -0700, Jens Axboe wrote: >>> On 1/11/18 2:41 AM, Paolo

Re: [for-4.16 PATCH v5 2/4] block: properly protect the 'queue' kobj in blk_unregister_queue

On Fri, Jan 12, 2018 at 10:06:04AM -0500, Mike Snitzer wrote: > The original commit e9a823fb34a8b (block: fix warning when I/O elevator > is changed as request_queue is being removed) is pretty conflated. > "conflated" because the resource being protected by q->sysfs_lock isn't > the queue_flags

Re: [PATCH IMPROVEMENT] block, bfq: limit sectors served with interactive weight raising

On 1/12/18 3:20 AM, Paolo Valente wrote: > > >> Il giorno 12 gen 2018, alle ore 11:15, Holger Hoffstätte >> ha scritto: >> >> On 01/12/18 06:58, Paolo Valente wrote: >>> >>> Il giorno 28 dic 2017, alle ore 15:00, Holger Hoffstätte

[for-4.16 PATCH v5 1/4] block: only bdi_unregister() in del_gendisk() if !GENHD_FL_HIDDEN

device_add_disk() will only call bdi_register_owner() if !GENHD_FL_HIDDEN, so it follows that del_gendisk() should only call bdi_unregister() if !GENHD_FL_HIDDEN. Found with code inspection. bdi_unregister() won't do any harm if bdi_register_owner() wasn't used but best to avoid the unnecessary

[for-4.16 PATCH v5 2/4] block: properly protect the 'queue' kobj in blk_unregister_queue

The original commit e9a823fb34a8b (block: fix warning when I/O elevator is changed as request_queue is being removed) is pretty conflated. "conflated" because the resource being protected by q->sysfs_lock isn't the queue_flags (it is the 'queue' kobj). q->sysfs_lock serializes __elevator_change()

[for-4.16 PATCH v5 0/4] block/dm: allow DM to defer blk_register_queue() until ready

Hi Jens, I'm submitting this v5 with more feeling now ;) I've distilled the changes down to be quite minimal. Hopefully this will help you and others review. I've also done a dry-run of applying 4.16 block changes and then merging dm-4.16; no merge conflicts:

[for-4.16 PATCH v5 3/4] block: allow gendisk's request_queue registration to be deferred

Since I can remember DM has forced the block layer to allow the allocation and initialization of the request_queue to be distinct operations. Reason for this is block/genhd.c:add_disk() has requires that the request_queue (and associated bdi) be tied to the gendisk before add_disk() is called --

[for-4.16 PATCH v5 4/4] dm: fix incomplete request_queue initialization

DM is no longer prone to having its request_queue be improperly initialized. Summary of changes: - defer DM's blk_register_queue() from add_disk()-time until dm_setup_md_queue() by using add_disk_no_queue_reg() in alloc_dev(). - dm_setup_md_queue() is updated to fully initialize DM's

Re: [for-4.16 PATCH v4 2/4] block: use queue_lock when clearing QUEUE_FLAG_REGISTERED in blk_unregister_queue

On Fri, Jan 12 2018 at 9:14am -0500, Ming Lei wrote: > On Fri, Jan 12, 2018 at 07:53:40AM -0500, Mike Snitzer wrote: > > On Fri, Jan 12 2018 at 2:09am -0500, > > Ming Lei wrote: > > > > > On Thu, Jan 11, 2018 at 03:14:15PM -0500, Mike Snitzer wrote:

Re: [for-4.16 PATCH v4 2/4] block: use queue_lock when clearing QUEUE_FLAG_REGISTERED in blk_unregister_queue

On Fri, Jan 12, 2018 at 07:53:40AM -0500, Mike Snitzer wrote: > On Fri, Jan 12 2018 at 2:09am -0500, > Ming Lei wrote: > > > On Thu, Jan 11, 2018 at 03:14:15PM -0500, Mike Snitzer wrote: > > > blk_unregister_queue() must protect against any modifications of > > >

Re: [for-4.16 PATCH v4 2/4] block: use queue_lock when clearing QUEUE_FLAG_REGISTERED in blk_unregister_queue

On Fri, Jan 12 2018 at 2:09am -0500, Ming Lei wrote: > On Thu, Jan 11, 2018 at 03:14:15PM -0500, Mike Snitzer wrote: > > blk_unregister_queue() must protect against any modifications of > > q->queue_flags (not just those performed in blk-sysfs.c). Therefore > >

Re: [PATCH 0/2] blk-mq: support physical CPU hotplug

On Fri, Jan 12, 2018 at 09:12:24AM +0100, Christian Borntraeger wrote: > I think we also need cc stable for this. The bug was introduced with > > commit 4b855ad37194f7bdbb200ce7a1c7051fecb56a08 upstream. > ("blk-mq: Create hctx for each present CPU") > > and that was even backported into 4.12

Re: [PATCH IMPROVEMENT] block, bfq: limit sectors served with interactive weight raising

> Il giorno 12 gen 2018, alle ore 11:15, Holger Hoffstätte > ha scritto: > > On 01/12/18 06:58, Paolo Valente wrote: >> >> >>> Il giorno 28 dic 2017, alle ore 15:00, Holger Hoffstätte >>> ha scritto: >>> >>> >>> On 12/28/17

Re: [PATCH IMPROVEMENT] block, bfq: limit sectors served with interactive weight raising

On 01/12/18 06:58, Paolo Valente wrote: > > >> Il giorno 28 dic 2017, alle ore 15:00, Holger Hoffstätte >> ha scritto: >> >> >> On 12/28/17 12:19, Paolo Valente wrote: >> (snip half a tech report ;) >> >> So either this or the previous patch ("limit tags for

Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000436

> Il giorno 12 gen 2018, alle ore 05:18, Ming Lei ha > scritto: > > On Thu, Jan 11, 2018 at 08:40:54AM -0700, Jens Axboe wrote: >> On 1/11/18 2:41 AM, Paolo Valente wrote: >>> >>> Il giorno 11 gen 2018, alle ore 10:30, Paolo Valente

Re: [PATCH 0/2] blk-mq: support physical CPU hotplug

I think we also need cc stable for this. The bug was introduced with commit 4b855ad37194f7bdbb200ce7a1c7051fecb56a08 upstream. ("blk-mq: Create hctx for each present CPU") and that was even backported into 4.12 stable. On 01/12/2018 03:53 AM, Ming Lei wrote: > Hi, > > This two patches

Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000436

> Il giorno 11 gen 2018, alle ore 16:40, Jens Axboe ha > scritto: > > On 1/11/18 2:41 AM, Paolo Valente wrote: >> >> >>> Il giorno 11 gen 2018, alle ore 10:30, Paolo Valente >>> ha scritto: >>> >>> >>> Il giorno 10 gen 2018, alle ore