On Wed, 2017-10-04 at 23:31 +0800, Ming Lei wrote:
> On Wed, Oct 04, 2017 at 03:18:45PM +0000, Bart Van Assche wrote:
> > On Wed, 2017-10-04 at 15:53 +0800, Ming Lei wrote:
> > > 2) RCU read lock is missed in fast path
> >
> > Did you really post this as a rev
On Wed, 2017-10-04 at 03:16 +0200, Luis R. Rodriguez wrote:
> On Mon, Oct 02, 2017 at 03:52:12PM -0700, Bart Van Assche wrote:
> > diff --git a/drivers/md/md.c b/drivers/md/md.c
> > index 3f7426120a3b..a2cf2a93b0cb 100644
> > --- a/drivers/md/md.c
> > +++ b/drivers/md/m
On Wed, 2017-10-04 at 09:06 +0200, Christoph Hellwig wrote:
> As mentioned before - if you pass BLK_MQ_REQ_* to blk_queue_enter
> this should become a bit nicer without the need for two magic bool
> parameters.
Hello Christoph,
I will make that change. Sorry that I missed it in v5 of this patch
On Wed, 2017-10-04 at 09:06 +0200, Christoph Hellwig wrote:
> > + /*
> > +* Ensure that the effect of blk_set_preempt_only() is globally
> > +* visible before unfreezing the queue.
> > +*/
> > + if (err == 0)
> > + synchronize_rcu();
>
> I don't understand why we'd need
On Wed, 2017-10-04 at 09:04 +0200, Christoph Hellwig wrote:
> > + /*
> > +* Do not attempt to freeze the queue of an already quiesced device
> > +* because that could result in a deadlock.
> > +*/
> > + freeze = sdev->sdev_state == SDEV_RUNNING;
> > + if (freeze)
> > +
On Wed, 2017-10-04 at 19:30 +0800, Ming Lei wrote:
> Last time, I asked which issue is fixed by this patch, but
> never get answered, so again, what is issue fixed by
> this patch?
That's not correct. I did answer your question. See e.g.
https://marc.info/?l=linux-block=150695879309606.
> Given
On Wed, 2017-10-04 at 18:05 +1100, Dave Chinner wrote:
> Basically, before thawing filesystems the rest of the kernel
> infrastructure needs to have been restarted. i.e. the order
> needs to be:
>
> freeze userspace
> freeze filesystems
> freeze kernel threads
> freeze workqueues
>
> thaw
On Wed, 2017-10-04 at 08:56 +0200, Christoph Hellwig wrote:
> can you guys please work a little better together? We've now got two
> patchsets that are getting very similar.
>
> Bart, please at least CC Ming when you send out the patches.
Hello Christoph,
Sorry for the low level of
On Wed, 2017-10-04 at 15:53 +0800, Ming Lei wrote:
> I have commented on Bart's patchset before, but my comments
> never gets addressed:
>
> 1) no MD changes required on this issue
I did not address that comment because you have another view on how suspend
and resume should work than the rest of
On Tue, 2017-10-03 at 13:47 -0700, Matthew Wilcox wrote:
> The SCSI layer can send SCSI commands; they aren't I/Os in the sense that
> they do reads and writes to media, but they are block requests. Maybe those
> should be allowed even to frozen devices?
Hello Matthew,
I think only RQF_PM
On Tue, 2017-10-03 at 09:19 +0900, Damien Le Moal wrote:
> On 10/3/17 08:44, Bart Van Assche wrote:
> > On Mon, 2017-10-02 at 16:15 +0900, Damien Le Moal wrote:
> > > static void deadline_wunlock_zone(struct deadline_data *dd,
> > >
On Tue, 2017-10-03 at 22:23 +0200, Luis R. Rodriguez wrote:
> On Tue, Oct 03, 2017 at 08:02:22PM +0000, Bart Van Assche wrote:
> > On Tue, 2017-10-03 at 11:53 -0700, Luis R. Rodriguez wrote:
> > > +static bool super_allows_freeze(struct super_block *sb)
> > > +{
&
On Tue, 2017-10-03 at 22:17 +0200, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Bart Van Assche wrote:
> > What about the many drivers outside filesystems that use the
> > set_freezable() / try_to_freeze() / wait_event_freezable() API?
>
> Many/most of them are just completel
On Tue, 2017-10-03 at 11:53 -0700, Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
Many subsystems use system_freezable_wq and/or
On Tue, 2017-10-03 at 11:53 -0700, Luis R. Rodriguez wrote:
> +static bool super_allows_freeze(struct super_block *sb)
> +{
> + return !!(sb->s_type->fs_flags & FS_FREEZE_ON_SUSPEND);
> +}
A minor comment: if "!!" would be left out the compiler will perform the
conversion from int to bool
On Tue, 2017-10-03 at 22:04 +0800, Ming Lei wrote:
> Block layer need to call this function after holding
> rcu lock in a real hot path, so introduce this helper.
Since it is allowed to nest rcu_read_lock_sched() calls I don't think
that this patch is necessary.
Bart.
On Tue, 2017-10-03 at 10:47 +0200, Christoph Hellwig wrote:
> -static struct request *blk_pm_peek_request(struct request_queue *q,
> -struct request *rq)
> +static bool blk_pm_allow_request(struct request *rq)
> {
> - if (q->dev && (q->rpm_status ==
On Mon, 2017-10-02 at 16:15 +0900, Damien Le Moal wrote:
> When dispatching write requests to a zoned block device, only allow
> requests targeting an unlocked zone. Requests targeting a locked zone
> are left in the scheduler queue to preserve the initial write order.
> If no write request can be
e request is requeued (inserted).
Anyway:
Reviewed-by: Bart Van Assche <bart.vanass...@wdc.com>
. per-zone write locking ..."? Anyway:
Reviewed-by: Bart Van Assche <bart.vanass...@wdc.com>
Introduce md_stop_all_writes() because the next patch will add
a second caller for this function. Rename md_notifier into
md_reboot_notifier to avoid that the name of this notifier will
become confusing due to the next patch. This patch does not
change any functionality.
Signed-off-by: Bart Van
will restart after
the system is resumed and a message similar to the following
will appear in the system log:
md: md0: data-check interrupted.
Additionally, only allow resync or reshape activity to be
started after system freezing is over.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com&
ed a comment and made sure
REQ_NOWAIT is handled properly in blk_old_get_request() ]
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Reviewed-by: Christoph Hellwig <h...@lst.de>
Cc: Ming Lei <ming@redhat.com>
Cc: Hannes Reinecke <h...@suse.com>
Cc: Johannes Thumshirn
that corresponds to this
request.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Ming Lei <ming@redhat.com>
Cc: Christoph Hellwig <h...@lst.de>
Cc: Hannes Reinecke <h...@suse.com>
Cc: Johannes Thumshirn <jthumsh...@suse.de>
---
block/blk-mq-debugfs.c| 2 +-
On Mon, 2017-10-02 at 16:15 +0900, Damien Le Moal wrote:
> + * There is no write constraints on conventional zones. So any write
^^
are?
Anyway:
Reviewed-by: Bart Van Assche <bart.vanass...@wdc.com>
; the helper sd_zbc_alloc_zone_bitmap(). Using this helper, wait for the
> disk capacity and number of zones to stabilize on the second
> revalidation pass to allocate and initialize the bitmaps.
Reviewed-by: Bart Van Assche <bart.vanass...@wdc.com>
On Mon, 2017-10-02 at 16:15 +0900, Damien Le Moal wrote:
> Fix comments style (use kernel-doc style) and content to clarify some
> functions. Also fix some functions signature indentation and remove a
> useless blank line in sd_zbc_read_zones().
Reviewed-by: Bart Van Assche <
On Sat, 2017-09-30 at 14:12 +0800, Ming Lei wrote:
> +void blk_set_preempt_only(struct request_queue *q, bool preempt_only)
> +{
> + blk_mq_freeze_queue(q);
> + if (preempt_only)
> + queue_flag_set_unlocked(QUEUE_FLAG_PREEMPT_ONLY, q);
> + else
> +
On Sat, 2017-09-30 at 14:12 +0800, Ming Lei wrote:
> @@ -1395,16 +1401,21 @@ static struct request *blk_old_get_request(struct
> request_queue *q,
> unsigned int op, gfp_t gfp_mask)
> {
> struct request *rq;
> + int ret = 0;
>
>
On Mon, 2017-10-02 at 15:47 +0200, Christoph Hellwig wrote:
> > +void blk_set_preempt_only(struct request_queue *q, bool preempt_only)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(q->queue_lock, flags);
> > + if (preempt_only)
> > +
On Sat, 2017-09-30 at 10:06 +0200, Jens Axboe wrote:
> For some reason, the laptop mode IO completion notified was never wired
> up for blk-mq. Ensure that we trigger the callback appropriately, to arm
> the laptop mode flush timer.
Reviewed-by: Bart Van Assche <bart.vanass...@wdc.com>
On Wed, 2017-09-27 at 19:00 +0800, Ming Lei wrote:
> With current linus tree, SCSI I/O is prevented from being dispatch to
> device during suspend by SCSI quiesce, and will be dispatched again
> in resume. With Safe SCSI quiesce[1], any underlying IO request will
> stop at blk_queue_enter() during
On Wed, 2017-09-27 at 13:48 +0800, Ming Lei wrote:
> @@ -2928,12 +2929,28 @@ scsi_device_quiesce(struct scsi_device *sdev)
> {
> int err;
>
> + /*
> + * Simply quiesing SCSI device isn't safe, it is easy
> + * to use up requests because all these allocated requests
> +
On Wed, 2017-09-27 at 06:23 +0800, Ming Lei wrote:
> mutex_lock(>state_mutex);
> err = scsi_device_set_state(sdev, SDEV_QUIESCE);
> if (err == 0)
> blk_set_preempt_only(q, true);
> mutex_unlock(>state_mutex);
>
> if (err)
>
On Tue, 2017-09-26 at 22:59 +0800, Ming Lei wrote:
> On Tue, Sep 26, 2017 at 02:42:07PM +0000, Bart Van Assche wrote:
> > On Tue, 2017-09-26 at 19:17 +0800, Ming Lei wrote:
> > > Just test this patch a bit and the following failure of freezing task
> > >
On Tue, 2017-09-26 at 22:54 +0800, Ming Lei wrote:
> On Tue, Sep 26, 2017 at 02:29:06PM +0000, Bart Van Assche wrote:
> > On Tue, 2017-09-26 at 17:15 +0800, Ming Lei wrote:
> > > No, if you only address issue on MD device, that is definitely not
> > >
On Tue, 2017-09-26 at 16:32 +0800, Ming Lei wrote:
> On Mon, Sep 25, 2017 at 11:13:47PM +0000, Bart Van Assche wrote:
> > Sorry but I disagree. I'm using RCU to achieve the same effect as a barrier
> > and to move the cost of the barrier from the reader to the updater. See
On Tue, 2017-09-26 at 19:17 +0800, Ming Lei wrote:
> Just test this patch a bit and the following failure of freezing task
> is triggered during suspend: [ ... ]
What kernel version did you start from and which patches were applied on top of
that kernel? Only patch 1/7 or all seven patches? What
On Tue, 2017-09-26 at 16:13 +0800, Ming Lei wrote:
> I am pretty sure that suspend/resume can survive when resync in progress
> with my patchset applied on RAID1, without any MD change.
The above shows that you do not understand how suspend and resume works.
In the documents in the directory
On Tue, 2017-09-26 at 17:15 +0800, Ming Lei wrote:
> No, if you only address issue on MD device, that is definitely not
> alternative of my patchset.
A clarification: my patch series not only fixes suspend and resume for
md-on-SCSI
but also for all other scenario's in which resume locks up due
On Tue, 2017-09-26 at 16:50 +0800, Ming Lei wrote:
> If you don't consider to change mpath into block in .queue_rq() now,
> please take this patch first, and I am sure this way is correct, and
> even it can be thought as a fix.
As I explained earlier, it would be wrong to take this patch upstream
On Tue, 2017-09-26 at 06:59 +0800, Ming Lei wrote:
> On Mon, Sep 25, 2017 at 01:29:24PM -0700, Bart Van Assche wrote:
> > +int blk_queue_enter(struct request_queue *q, bool nowait, bool preempt)
> > {
> > while (true) {
> > int ret;
> >
> >
On Tue, 2017-09-26 at 07:04 +0800, Ming Lei wrote:
> On Mon, Sep 25, 2017 at 01:29:18PM -0700, Bart Van Assche wrote:
> > Some people use the md driver on laptops and use the suspend and
> > resume functionality. Since it is essential that submitting of
> > new I/O request
On Tue, 2017-09-26 at 06:51 +0800, Ming Lei wrote:
> On Mon, Sep 25, 2017 at 04:20:20PM +0000, Bart Van Assche wrote:
> > So that means that you have not noticed that it is safe to leave out that
> > smp_rmp() call because blk-mq queue freezing and unfreezing waits for a
>
On Tue, 2017-09-26 at 06:45 +0800, Ming Lei wrote:
> On Mon, Sep 25, 2017 at 04:22:29PM +0000, Bart Van Assche wrote:
> > On Mon, 2017-09-25 at 10:38 +0800, Ming Lei wrote:
> > > On Fri, Sep 22, 2017 at 03:14:00PM -0700, Bart Van Assche wrote:
> > > > Some peopl
On Mon, 2017-09-25 at 15:14 +0900, Damien Le Moal wrote:
> - return rq_entry_fifo(dd->fifo_list[data_dir].next);
> + if (!dd->zones_wlock || data_dir == READ)
> + return rq_entry_fifo(dd->fifo_list[data_dir].next);
> +
> + spin_lock_irqsave(>zone_lock, flags);
> +
> +
On Mon, 2017-09-25 at 15:14 +0900, Damien Le Moal wrote:
> +static inline bool deadline_request_needs_zone_wlock(struct deadline_data
> *dd,
> + struct request *rq)
> +{
> +
> + if (!dd->zones_wlock)
> + return false;
> +
> + if
).
Reviewed-by: Bart Van Assche <bart.vanass...@wdc.com>
On Mon, 2017-09-25 at 15:14 +0900, Damien Le Moal wrote:
> Modify mq-dealine init_queue and exit_queue elevator methods to handle
^^
mq-deadline ?
> +static int deadline_init_zones_wlock(struct request_queue *q,
> + struct deadline_data
On Mon, 2017-09-25 at 15:14 +0900, Damien Le Moal wrote:
> + return kzalloc_node(BITS_TO_LONGS(sdkp->nr_zones)
> + * sizeof(unsigned long),
Does this perhaps fit on one line?
> +/**
> + * sd_zbc_get_seq_zones - Parse report zones reply to identify sequential
> zones
zed by stacking drivers (device mappers) handling zoned block
> devices (e.g. dm-linear).
Reviewed-by: Bart Van Assche <bart.vanass...@wdc.com>
check_zone_size().
>
> No functional change is introduced by this patch.
>
> Signed-off-by: Damien Le Moal <damien.lem...@wdc.com>
> Reviewed-by: Christoph Hellwig <h...@lst.de>
Reviewed-by: Bart Van Assche <bart.vanass...@wdc.com>
that corresponds to this
request.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Ming Lei <ming@redhat.com>
Cc: Christoph Hellwig <h...@lst.de>
Cc: Hannes Reinecke <h...@suse.com>
Cc: Johannes Thumshirn <jthumsh...@suse.de>
---
block/blk-mq-debugfs.c| 2 +-
Avoid that it can take 200 ms too long to wait for requests to
finish. Note: blk_mq_freeze_queue() uses a wait queue to wait
for ongoing requests to finish.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: Mi
ferences: "I/O hangs after resuming from suspend-to-ram"
(https://marc.info/?l=linux-block=150340235201348).
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: Ming Lei <ming@redhat.com>
Cc: Christ
Some people use the md driver on laptops and use the suspend and
resume functionality. Since it is essential that submitting of
new I/O requests stops before device quiescing starts, make the
md resync and reshape threads freezable.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com&
This flag will be used in the next patch to let the block layer
core know whether or not a SCSI request queue has been quiesced.
A quiesced SCSI queue namely only processes RQF_PREEMPT requests.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Ming Lei <ming@redha
Make the quiesce state visible to the block layer for the next
patch in this series.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: Ming Lei <ming@redhat.com>
Cc: Christoph Hellwig <h...@lst.de>
ch series:
- Changed the approach and rewrote the patch series.
Bart Van Assche (6):
md: Make md resync and reshape threads freezable
block: Convert RQF_PREEMPT into REQ_PREEMPT
block: Add the QUEUE_FLAG_PREEMPT_ONLY request queue flag
scsi-mq: Reduce suspend latency
scsi: Set QUEUE_FLA
ed a comment and made sure
REQ_NOWAIT is handled properly in blk_old_get_request() ]
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Ming Lei <ming@redhat.com>
Cc: Christoph Hellwig <h...@lst.de>
Cc: Hannes Reinecke <h...@suse.com>
Cc: Johannes Thumshirn <jt
On Mon, 2017-09-25 at 10:38 +0800, Ming Lei wrote:
> On Fri, Sep 22, 2017 at 03:14:00PM -0700, Bart Van Assche wrote:
> > Some people use the md driver on laptops and use the suspend and
> > resume functionality. Since it is essential that submitting of
> > new I/O request
On Mon, 2017-09-25 at 10:26 +0800, Ming Lei wrote:
> On Fri, Sep 22, 2017 at 03:14:04PM -0700, Bart Van Assche wrote:
> > +int blk_queue_enter(struct request_queue *q, bool nowait, bool preempt)
> > {
> > while (true) {
> > int ret;
> >
> >
On Mon, 2017-09-25 at 10:36 +0800, Ming Lei wrote:
> On Sat, Sep 23, 2017 at 6:13 AM, Bart Van Assche <bart.vanass...@wdc.com>
> wrote:
> > It is known that during the resume following a hibernate sometimes the
> > system hangs instead of coming up properly.
On Mon, 2017-09-25 at 11:06 +0800, Ming Lei wrote:
> On Fri, Sep 22, 2017 at 05:54:48PM +0000, Bart Van Assche wrote:
> > On Sat, 2017-09-23 at 01:44 +0800, Ming Lei wrote:
> > > On Fri, Sep 22, 2017 at 03:06:16PM +0000, Bart Van Assche wrote:
> > > > On Fri, 2017-
that corresponds to this
request.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Ming Lei <ming@redhat.com>
Cc: Christoph Hellwig <h...@lst.de>
Cc: Hannes Reinecke <h...@suse.com>
Cc: Johannes Thumshirn <jthumsh...@suse.de>
---
block/blk-mq-debugfs.c| 2 +-
This flag will be used in the next patch to let the block layer
core know whether or not a SCSI request queue has been quiesced.
A quiesced SCSI queue namely only processes RQF_PREEMPT requests.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Ming Lei <ming@redha
Some people use the md driver on laptops and use the suspend and
resume functionality. Since it is essential that submitting of
new I/O requests stops before device quiescing starts, make the
md resync and reshape threads freezable.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com&
Avoid that it can take 200 ms too long to wait for requests to
finish. Note: blk_mq_freeze_queue() uses a wait queue to wait
for ongoing requests to finish.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: Mi
ferences: "I/O hangs after resuming from suspend-to-ram"
(https://marc.info/?l=linux-block=150340235201348).
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: Ming Lei <ming@redhat.com>
Cc: Christ
nsider these changes for kernel v4.15.
Thanks,
Bart.
Changes between v2 and v3:
- Made md kernel threads freezable.
- Changed the approach for quiescing SCSI devices again.
- Addressed Ming's review comments.
Changes compared to v1 of this patch series:
- Changed the approach and rewrote the pat
Make the quiesce state visible to the block layer for the next
patch in this series.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: Ming Lei <ming@redhat.com>
Cc: Christoph Hellwig <h...@lst.de>
On Sat, 2017-09-23 at 01:44 +0800, Ming Lei wrote:
> On Fri, Sep 22, 2017 at 03:06:16PM +0000, Bart Van Assche wrote:
> > On Fri, 2017-09-22 at 09:35 +0800, Ming Lei wrote:
> > > + /*
> > > + * blk-mq's SCHED_RESTART can cover this requeue, so
> >
On Fri, 2017-09-22 at 09:35 +0800, Ming Lei wrote:
> + /*
> + * blk-mq's SCHED_RESTART can cover this requeue, so
> + * we needn't to deal with it by DELAY_REQUEUE. More
> + * importantly, we have to return DM_MAPIO_REQUEUE
> + * so
On Fri, 2017-09-22 at 07:53 +0800, Ming Lei wrote:
> Then that is simply not enough since the issue is that request pool can
> be used up easily when SCSI device is quiesced, then no request is left
> for RQF_PREEMPT(PM), and I/O hang is triggered.
>
> It has been discussed for long time, I am
On Fri, 2017-09-22 at 07:25 +0800, Ming Lei wrote:
> On Thu, Sep 21, 2017 at 10:43:26PM +0000, Bart Van Assche wrote:
> > On Fri, 2017-09-22 at 06:06 +0800, Ming Lei wrote:
> > > On Thu, Sep 21, 2017 at 02:22:55PM -0700, Bart Van Assche wrote:
>
On Fri, 2017-09-22 at 06:04 +0800, Ming Lei wrote:
> On Thu, Sep 21, 2017 at 02:22:54PM -0700, Bart Van Assche wrote:
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -1429,11 +1429,18 @@ struct request *blk_get_request(struct
> > reques
On Fri, 2017-09-22 at 06:06 +0800, Ming Lei wrote:
> On Thu, Sep 21, 2017 at 02:22:55PM -0700, Bart Van Assche wrote:
> > + } else {
> > scsi_run_queue(q);
> > + while (atomic_read(>device_busy)) {
> > +
nsider these changes for kernel v4.15.
Thanks,
Bart.
Changes compared to v1 of this patch series:
- Changed the approach and rewrote the patch series.
Bart Van Assche (4):
block: Convert RQF_PREEMPT into REQ_PREEMPT
block: Add the QUEUE_PREEMPT_ONLY request queue flag
block, scsi: Make
that corresponds to this
request.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Ming Lei <ming@redhat.com>
Cc: Christoph Hellwig <h...@lst.de>
Cc: Hannes Reinecke <h...@suse.com>
Cc: Johannes Thumshirn <jthumsh...@suse.de>
---
block/blk-mq-debugfs.c| 2 +-
This flag will be used in the next patch to let the block layer
core know whether or not a SCSI request queue has been quiesced.
A quiesced SCSI queue namely only processes RQF_PREEMPT requests.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Ming Lei <ming@redha
Avoid that it can take 200 ms too long to wait for ongoing requests
to finish. Note: blk_mq_freeze_queue() uses a wait queue to wait
for ongoing requests to finish.
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: Mi
;I/O hangs after resuming from suspend-to-ram"
(https://marc.info/?l=linux-block=150340235201348).
Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Martin K. Petersen <martin.peter...@oracle.com>
Cc: Ming Lei <ming@redhat.com>
Cc: Christoph Hellwig <h...@ls
ned-off-by: Bart Van Assche <bart.vanass...@wdc.com>
Cc: Ming Lei <ming@redhat.com>
Cc: <sta...@vger.kernel.org> # v4.13+
---
block/blk-mq.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 3f18cff80050..fc2001
On Wed, 2017-09-20 at 06:44 +0800, Ming Lei wrote:
> For this issue, it isn't same between SCSI and dm-rq.
>
> We don't need to run queue in .end_io of dm, and the theory is
> simple, otherwise it isn't performance issue, and should be I/O hang.
>
> 1) every dm-rq's request is 1:1 mapped to
On Wed, 2017-09-20 at 00:55 +0800, Ming Lei wrote:
> On Wed, Sep 20, 2017 at 12:49 AM, Bart Van Assche
> <bart.vanass...@wdc.com> wrote:
> > On Wed, 2017-09-20 at 00:04 +0800, Ming Lei wrote:
> > > Run queue at end_io is definitely wrong, because blk-mq has SCHED_RESTA
On Wed, 2017-09-20 at 00:04 +0800, Ming Lei wrote:
> Run queue at end_io is definitely wrong, because blk-mq has SCHED_RESTART
> to do that already.
Sorry but I disagree. If SCHED_RESTART is set that causes the blk-mq core to
reexamine the software queues and the hctx dispatch list but not the
On Tue, 2017-09-19 at 11:48 -0400, Mike Snitzer wrote:
> This thread proves that it is definitely brittle to be relying on fixed
> delays like this:
> https://patchwork.kernel.org/patch/9703249/
Hello Mike,
Sorry but I think that's a misinterpretation of my patch. I came up with that
patch
On Tue, 2017-09-19 at 13:43 +0800, Ming Lei wrote:
> On Mon, Sep 18, 2017 at 03:18:16PM +0000, Bart Van Assche wrote:
> > If you are still looking at removing the blk_mq_delay_run_hw_queue() calls
> > then I think you are looking in the wrong direction. What kind of problem
>
On Tue, 2017-09-19 at 11:07 -0400, Keith Busch wrote:
> The problem is when blk-mq's timeout handler prevents the request from
> completing, and doesn't leave any indication the driver requested to
> complete it. Who is responsible for completing that request now?
Hello Keith,
My understanding
On Mon, 2017-09-18 at 21:55 -0400, Keith Busch wrote:
> The only way to complete that request now is if the timeout
> handler returns BLK_EH_HANDLED, but the scsi-mq abort path returns
> BLK_EH_NOT_HANDLED on success (very few drivers actually return
> BLK_EH_HANDLED).
>
> After the timeout
On Mon, 2017-09-18 at 19:08 -0400, Keith Busch wrote:
> On Mon, Sep 18, 2017 at 10:53:12PM +0000, Bart Van Assche wrote:
> > Are you sure that scenario can happen? The blk-mq core calls
> > test_and_set_bit()
> > for the REQ_ATOM_COMPLETE flag before any completi
On Mon, 2017-09-18 at 18:39 -0400, Keith Busch wrote:
> The nvme driver's use of blk_mq_reinit_tagset only happens during
> controller initialisation, but I'm seeing lost commands well after that
> during normal and stable running.
>
> The timing is pretty narrow to hit, but I'm pretty sure this
On Mon, 2017-09-18 at 18:03 -0400, Keith Busch wrote:
> I think we've always known it's possible to lose a request during timeout
> handling, but just accepted that possibility. It seems to be causing
> problems, though, leading to unnecessary error escalation and IO failures.
>
> The possiblity
On Sat, 2017-09-16 at 19:37 -0700, Waiman Long wrote:
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 339e737..330b572 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -448,7 +448,7 @@ struct block_device {
>
> /* The counter of freeze processes */
>
On Sun, 2017-09-17 at 20:40 +0800, Ming Lei wrote:
> "if no request has completed before the delay has expired" can't be a
> reason to rerun the queue, because the queue can still be busy.
That statement of you shows that there are important aspects of the SCSI
core and dm-mpath driver that you
On Sat, 2017-09-16 at 07:35 +0900, Damien Le Moal wrote:
> rw16 is mandatory for ZBC drives. So it has to be set to true. If the
> HBA does not support rw16 (why would that happen ?), then the disk
> should not be used.
It's good that all HBAs support rw16. But it's nontrivial to analyze whether
On Sat, 2017-09-16 at 00:44 +0800, Ming Lei wrote:
> +static void save_path_queue_depth(struct pgpath *p)
> +{
> + struct request_queue *q = bdev_get_queue(p->path.dev->bdev);
> +
> + p->old_nr_requests = q->nr_requests;
> + p->queue_depth = q->queue_depth;
> +
> + /* one extra
On Sat, 2017-09-16 at 00:44 +0800, Ming Lei wrote:
> 1) lpfc.lpfc_lun_queue_depth=3, so that it is same with .cmd_per_lun
Nobody I know uses such a low queue depth for the lpfc driver. Please also
include performance results for a more realistic queue depth.
Thanks,
Bart.
On Fri, 2017-09-15 at 19:51 +0200, h...@lst.de wrote:
> On Fri, Sep 15, 2017 at 02:51:03PM +0000, Bart Van Assche wrote:
> > On Fri, 2017-09-15 at 19:06 +0900, Damien Le Moal wrote:
> > > Rearrange sd_zbc_setup() to include use_16_for_rw and use_10_for_rw
> > > assignmen
On Sat, 2017-09-16 at 00:44 +0800, Ming Lei wrote:
> ---
> |v4.13+ |v4.13+
> |+scsi_mq_perf |+scsi_mq_perf+patches
> -
> IOPS(K) |MQ-DEADLINE|MQ-DEADLINE
>
1101 - 1200 of 2095 matches
Mail list logo
