From: Tang Junhui
Hello Lyle:
Two questions:
1) In keys_contiguous(), you judge I/O contiguous in cache device, but not
in backing device. I think you should judge it by backing device (remove
PTR_CACHE() and use KEY_OFFSET() instead of PTR_OFFSET()?).
2) I did not see you combine samll contig
On 09/27/2017 07:48 AM, Ming Lei wrote:
> This usage is basically same with blk-mq, so that we can
> support to freeze legacy queue easily.
>
> Also 'wake_up_all(&q->mq_freeze_wq)' has to be moved
> into blk_set_queue_dying() since both legacy and blk-mq
> may wait on the wait queue of .mq_freeze_
Simply quiesing SCSI device and waiting for completeion of IO
dispatched to SCSI queue isn't safe, it is easy to use up
request pool because all allocated requests before can't
be dispatched when device is put in QIUESCE. Then no request
can be allocated for RQF_PREEMPT, and system may hang somewhe
We need to pass PREEMPT flags to blk_queue_enter()
for allocating request with RQF_PREEMPT in the
following patch.
Signed-off-by: Ming Lei
---
block/blk-core.c | 10 ++
block/blk-mq.c | 5 +++--
block/blk-timeout.c| 2 +-
fs/block_dev.c | 4 ++--
include/linu
This usage is basically same with blk-mq, so that we can
support to freeze legacy queue easily.
Also 'wake_up_all(&q->mq_freeze_wq)' has to be moved
into blk_set_queue_dying() since both legacy and blk-mq
may wait on the wait queue of .mq_freeze_wq.
Signed-off-by: Ming Lei
---
block/blk-core.c
When queue is in PREEMPT_ONLY mode, only RQF_PREEMPT request
can be allocated and dispatched, other requests won't be allowed
to enter I/O path.
This is useful for supporting safe SCSI quiesce.
Part of this patch is from Bart's '[PATCH v4 4∕7] block: Add the
QUEUE_FLAG_PREEMPT_ONLY
request queue
REQF_PREEMPT is a bit special because the request is required
to be dispatched to lld even when SCSI device is quiesced.
So this patch introduces __blk_get_request() and allows users to pass
RQF_PREEMPT flag in, then we can allow to allocate request of RQF_PREEMPT
when queue is in mode of PREEMPT
This patch just makes it explicitely.
Reviewed-by: Johannes Thumshirn
Signed-off-by: Ming Lei
---
block/blk-mq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 98a18609755e..6fd9f86fc86d 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.
Hi,
The current SCSI quiesce isn't safe and easy to trigger I/O deadlock.
Once SCSI device is put into QUIESCE, no new request except for
RQF_PREEMPT can be dispatched to SCSI successfully, and
scsi_device_quiesce() just simply waits for completion of I/Os
dispatched to SCSI stack. It isn't enoug
On Wed, Sep 27, 2017 at 03:43:11AM +, Bart Van Assche wrote:
> On Wed, 2017-09-27 at 06:23 +0800, Ming Lei wrote:
> > mutex_lock(&sdev->state_mutex);
> > err = scsi_device_set_state(sdev, SDEV_QUIESCE);
> > if (err == 0)
> > blk_set_preempt_only(q, true);
On Wed, 2017-09-27 at 06:23 +0800, Ming Lei wrote:
> mutex_lock(&sdev->state_mutex);
> err = scsi_device_set_state(sdev, SDEV_QUIESCE);
> if (err == 0)
> blk_set_preempt_only(q, true);
> mutex_unlock(&sdev->state_mutex);
>
> if (err)
>
From: Tang Junhui
It looks good to me,
I have noted this issue before.
Thanks.
---
Tang Junhui
> If an IO operation fails, and we didn't successfully read data from the
> cache, don't writeback invalid/partial data to the backing disk.
>
> Signed-off-by: Michael Lyle
> ---
> drivers/md/b
On Tue, 2017-09-26 at 22:59 +0800, Ming Lei wrote:
> On Tue, Sep 26, 2017 at 02:42:07PM +, 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
> > > is triggered during suspend: [ ... ]
> >
>
On Fri, Sep 22, 2017 at 2:37 PM, Adrian Hunter wrote:
> Export mmc_retune_hold_now() and mmc_retune_release() so they can be used
> by the block driver.
>
> Signed-off-by: Adrian Hunter
Actually you convert mmc_retune_hold_now() into a static inline, so the commit
message is a bit ambigous but
On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter wrote:
> Export mmc_start_bkops() so that the block driver can use it.
>
> Signed-off-by: Adrian Hunter
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Sep 22, 2017 at 2:37 PM, Adrian Hunter wrote:
> Export mmc_start_request() so that the block driver can use it.
>
> Signed-off-by: Adrian Hunter
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter wrote:
> Until mmc has blk-mq support fully implemented and tested, add a
> parameter use_blk_mq, default to false unless config option MMC_MQ_DEFAULT
> is selected.
>
> Signed-off-by: Adrian Hunter
> +config MMC_MQ_DEFAULT
> + bool "MMC: use
On Tue, Sep 26, 2017 at 08:17:59PM +, Bart Van Assche wrote:
> On Tue, 2017-09-26 at 22:54 +0800, Ming Lei wrote:
> > On Tue, Sep 26, 2017 at 02:29:06PM +, 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, tha
On Mon, Sep 25, 2017 at 01:29:22PM -0700, Bart Van Assche wrote:
> 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
> Cc: Martin K. Petersen
> Cc: Mi
On 22 September 2017 at 14:36, Adrian Hunter wrote:
> Hi
>
> Here is V9 of the hardware command queue patches without the software
> command queue patches, now using blk-mq and now with blk-mq support for
> non-CQE I/O.
>
> HW CMDQ offers 25% - 50% better random multi-threaded I/O. I see a slight
On Tue, 2017-09-26 at 22:54 +0800, Ming Lei wrote:
> On Tue, Sep 26, 2017 at 02:29:06PM +, 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
> > > alternative of my patchset.
> >
> > A clarific
Thanks everyone--
Yes, this looks good to me and works in testing.
Mike
On Tue, Sep 26, 2017 at 12:46 AM, Coly Li wrote:
> On 2017/9/26 下午12:38, Michael Lyle wrote:
>> I believe this introduces a critical bug.
>>
>> cl->list is used to link together the llists for both things waiting,
>> and fo
On 09/26/2017 08:02 PM, Shaohua Li wrote:
> The code is only for blkcg not for all cgroups
Added, thanks.
--
Jens Axboe
The code is only for blkcg not for all cgroups
Reported-by: kbuild test robot
Signed-off-by: Shaohua Li
---
drivers/block/loop.c| 2 +-
include/linux/kthread.h | 2 +-
kernel/kthread.c| 8
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/block/loop.c b
On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter wrote:
> Factor out some common code that will also be used with blk-mq.
>
> Signed-off-by: Adrian Hunter
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter wrote:
> Enhance mmc_blk_data_prep() to support CQE requests. That means adding
> some things that for non-CQE requests would be encoded into the command
> arguments - such as the block address, reliable-write flag, and data tag
> flag. Also the requ
On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter wrote:
> Use local variables in mmc_blk_data_prep() in preparation for adding CQE
> support which doesn't use the output variables.
>
> Signed-off-by: Adrian Hunter
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter wrote:
> Add core support for handling CQE requests, including starting, completing
> and recovering.
>
> Signed-off-by: Adrian Hunter
Looks straight-forward to me.
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter wrote:
> Enable or disable CQE when a card is added or removed respectively.
>
> Signed-off-by: Adrian Hunter
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter wrote:
> Enable the Command Queue if the host controller supports a command queue
> engine. It is not compatible with Packed Commands, so make a note of that in
> the
> comment.
>
> Signed-off-by: Adrian Hunter
Reviewed-by: Linus Walleij
Yours,
On Tue, Sep 26, 2017 at 02:40:36PM +, Bart Van Assche wrote:
> 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 under
On Tue, Sep 26, 2017 at 02:42:07PM +, 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
> > is triggered during suspend: [ ... ]
>
> What kernel version did you start from and which patches were
On Tue, Sep 26, 2017 at 02:29:06PM +, 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
> > alternative of my patchset.
>
> A clarification: my patch series not only fixes suspend and resume for
>
On Tue, 2017-09-26 at 16:32 +0800, Ming Lei wrote:
> On Mon, Sep 25, 2017 at 11:13:47PM +, 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 also
> > Paul E. McKenney
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 s
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 Docum
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 to
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
From: 10074136
> Code comments in alloc.c:bch_alloc_sectors() mentions a function
> name find_data_bucket(), the correct function name should be
> pick_data_bucket() indeed. bch_alloc_sectors() is a quite important
> function in bcache allocation code, fixing the typo may help
> other people to h
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 requests stops before device quiescing starts, make the
> md resync and reshape threads free
Hi Jens,
Michael Lyle catches a race bug in bcache 4.14 patch set. Here is the fix
for this issue. Could you please to pick it for 4.14-rc4 ? Then we don't need
to sta...@vger.kernel.org in next cycle.
Thanks in advance.
Coly Li
Commit 09b3efec ("bcache: Don't reinvent the wheel but use existing llist
API") replaces the following while loop by llist_for_each_entry(),
-
- while (reverse) {
- cl = container_of(reverse, struct closure, list);
- reverse = llist_next(reverse);
-
+ llist_
On Mon, Sep 25, 2017 at 01:29:17PM -0700, Bart Van Assche wrote:
> Hello Jens,
>
> It is known that during the resume following a hibernate, especially when
> using an md RAID1 array created on top of SCSI devices, sometimes the
> system hangs instead of coming up properly. This patch series fixes
On Mon, Sep 25, 2017 at 04:17:27PM +, Bart Van Assche wrote:
> On Mon, 2017-09-25 at 10:36 +0800, Ming Lei wrote:
> > On Sat, Sep 23, 2017 at 6:13 AM, Bart Van Assche
> > wrote:
> > > It is known that during the resume following a hibernate sometimes the
> > > system hangs instead of coming u
On Mon, Sep 25, 2017 at 12:17:03PM -0400, Mike Snitzer wrote:
> On Mon, Sep 25 2017 at 12:10pm -0400,
> Ming Lei wrote:
>
> > On Mon, Sep 25, 2017 at 03:23:16PM +, Bart Van Assche wrote:
> > > On Mon, 2017-09-25 at 11:06 +0800, Ming Lei wrote:
> > > > On Fri, Sep 22, 2017 at 05:54:48PM +,
On Tue, Sep 26, 2017 at 7:24 AM, Dave Chinner wrote:
> On Thu, Sep 21, 2017 at 09:43:41AM +0300, Amir Goldstein wrote:
>> On Thu, Sep 21, 2017 at 1:22 AM, Dave Chinner wrote:
>> > [cc lkml, PeterZ and Byungchul]
>> ...
>> > The thing is, this IO completion has nothing to do with the lower
>> > fi
On Mon, Sep 25, 2017 at 01:29:19PM -0700, Bart Van Assche wrote:
> From: Ming Lei
>
> This patch makes it possible to pause request allocation for
> the legacy block layer by calling blk_mq_freeze_queue() and
> blk_mq_unfreeze_queue().
>
> Signed-off-by: Ming Lei
> [ bvanassche: Combined two pa
On Mon, Sep 25, 2017 at 11:13:47PM +, Bart Van Assche wrote:
> 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) {
>
> -Original Message-
> From: Coly Li [mailto:i...@coly.li]
> Sent: Tuesday, September 26, 2017 5:00 PM
> To: Byungchul Park
> Subject: Fwd: [PATCH] bcache: use llist_for_each_entry_safe() in
> __closure_wake_up()
>
> Hi Byungchul,
>
> I posted the fix on linux-bcache mailing list, could y
On Tue, Sep 26, 2017 at 12:01:03PM +0800, Ming Lei wrote:
> On Mon, Sep 25, 2017 at 11:09:15PM +, Bart Van Assche wrote:
> > 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
On 2017/9/26 下午12:38, Michael Lyle wrote:
> I believe this introduces a critical bug.
>
> cl->list is used to link together the llists for both things waiting,
> and for things that are being woken.
>
> If a closure that is woken decides to wait again, it will corrupt the
> llist that __closure_w
Commit 09b3efec ("bcache: Don't reinvent the wheel but use existing llist
API") replaces the following while loop by llist_for_each_entry(),
-
- while (reverse) {
- cl = container_of(reverse, struct closure, list);
- reverse = llist_next(reverse);
-
+ llist_
On 2017/9/26 下午3:16, 박병철/선임연구원/SW
Platform(연)AOT팀(byungchul.p...@lge.com) wrote:
>> -Original Message-
>> From: Coly Li [mailto:i...@coly.li]
>> Sent: Tuesday, September 26, 2017 4:09 PM
>> To: Michael Lyle; Coly Li
>> Cc: linux-bca...@vger.kernel.org; linux-block@vger.kernel.org;
>> ax...@
On 2017/9/26 下午3:15, 박병철/선임연구원/SW
Platform(연)AOT팀(byungchul.p...@lge.com) wrote:
>> -Original Message-
>> From: Coly Li [mailto:i...@coly.li]
>> Sent: Tuesday, September 26, 2017 4:09 PM
>> To: 박병철/선임연구원/SW Platform(연)AOT팀(byungchul.p...@lge.com);
>> Michael Lyle; Coly Li
>> Cc: linux-bca..
> -Original Message-
> From: Coly Li [mailto:i...@coly.li]
> Sent: Tuesday, September 26, 2017 4:09 PM
> To: Michael Lyle; Coly Li
> Cc: linux-bca...@vger.kernel.org; linux-block@vger.kernel.org;
> ax...@kernel.dk; Eric Wheeler; Byungchul Park; Kent Overstreet
> Subject: Re: [PATCH 04/12] b
> -Original Message-
> From: Coly Li [mailto:i...@coly.li]
> Sent: Tuesday, September 26, 2017 4:09 PM
> To: 박병철/선임연구원/SW Platform(연)AOT팀(byungchul.p...@lge.com);
> Michael Lyle; Coly Li
> Cc: linux-bca...@vger.kernel.org; linux-block@vger.kernel.org;
> ax...@kernel.dk; Eric Wheeler; Kent O
On 2017/9/26 下午2:39, 박병철/선임연구원/SW
Platform(연)AOT팀(byungchul.p...@lge.com) wrote:
>> -Original Message-
>> From: Michael Lyle [mailto:ml...@lyle.org]
>> Sent: Tuesday, September 26, 2017 1:38 PM
>> To: Coly Li
>> Cc: linux-bca...@vger.kernel.org; linux-block@vger.kernel.org;
>> ax...@kernel.
On 2017/9/26 下午12:38, Michael Lyle wrote:
> I believe this introduces a critical bug.
>
> cl->list is used to link together the llists for both things waiting,
> and for things that are being woken.
>
> If a closure that is woken decides to wait again, it will corrupt the
> llist that __closure_w
58 matches
Mail list logo
