If hardware queues are stopped for some event, like the device has been
suspended by power management, requests allocated on that hardware queue
are indefinitely stuck causing a queue freeze to wait forever.
I have a problem with this patch. IMO, this is a general issue so, so
why do we tie a
@@ -1014,9 +1013,9 @@ static int nvme_rdma_map_data(struct nvme_rdma_queue
*queue,
}
Christoph, a little above here we still look at blk_rq_bytes(),
shouldn't that look at blk_rq_payload_bytes() too?
The check is ok for now as it's just zero vs non-zero. It's somewhat
broken for W
Hello Jens Axboe,
This is a semi-automatic email about new static checker warnings.
The patch bd166ef183c2: "blk-mq-sched: add framework for MQ capable
IO schedulers" from Jan 17, 2017, leads to the following Smatch
complaint:
block/elevator.c:234 elevator_init()
error: we previously as
On 01/19/2017 12:34 AM, Song Liu wrote:
>
> Media health monitoring is very important for large scale distributed storage
> systems.
> Traditionally, enterprise storage controllers maintain event logs for
> attached storage
> devices. However, these controller managed logs do not scale well for
On 2017/1/19 上午7:34, Song Liu wrote:
>
> Media health monitoring is very important for large scale distributed storage
> systems.
> Traditionally, enterprise storage controllers maintain event logs for
> attached storage
> devices. However, these controller managed logs do not scale well for la
On Wed, Jan 18, 2017 at 03:39:17PM -0500, Jeff Moyer wrote:
> Jan Kara writes:
>
> > On Tue 17-01-17 15:14:21, Vishal Verma wrote:
> >> Your note on the online repair does raise another tangentially related
> >> topic. Currently, if there are badblocks, writes via the bio submission
> >> path wil
-Original Message-
From: Jeff Moyer [mailto:jmo...@redhat.com]
Sent: Wednesday, January 18, 2017 12:48 PM
To: Slava Dubeyko
Cc: Jan Kara ; linux-nvd...@lists.01.org
; linux-block@vger.kernel.org; Viacheslav Dubeyko
; Linux FS Devel ;
lsf...@lists.linux-foundation.org
Subject: Re: [Lsf
On Wed, 2017-01-18 at 23:34 +, Song Liu wrote:
> Media health monitoring is very important for large scale distributed storage
> systems.
> Traditionally, enterprise storage controllers maintain event logs for
> attached storage
> devices. However, these controller managed logs do not scale
Media health monitoring is very important for large scale distributed storage
systems.
Traditionally, enterprise storage controllers maintain event logs for attached
storage
devices. However, these controller managed logs do not scale well for large
scale
distributed systems.
While designin
On Wed, Jan 18, 2017 at 02:21:48PM -0800, Jens Axboe wrote:
> On 01/18/2017 02:16 PM, Jens Axboe wrote:
> > On 01/18/2017 02:21 PM, Keith Busch wrote:
> >> Signed-off-by: Keith Busch
> >> Reviewed-by: Christoph Hellwig
> >> Reviewed-by: Sagi Grimberg
> >
> > Does it cause a warning anywhere? If
On 01/18/2017 02:16 PM, Jens Axboe wrote:
> On 01/18/2017 02:21 PM, Keith Busch wrote:
>> Signed-off-by: Keith Busch
>> Reviewed-by: Christoph Hellwig
>> Reviewed-by: Sagi Grimberg
>
> Does it cause a warning anywhere? If not, I'd rather not apply
> it, since it'll cause a merge conflict for 4.
On 01/18/2017 02:21 PM, Keith Busch wrote:
> Signed-off-by: Keith Busch
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Sagi Grimberg
Does it cause a warning anywhere? If not, I'd rather not apply
it, since it'll cause a merge conflict for 4.11 (and the problem
doesn't exist there).
--
Jens A
Signed-off-by: Keith Busch
Reviewed-by: Christoph Hellwig
Reviewed-by: Sagi Grimberg
---
block/blk-mq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index a8e67a1..c3400b5 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -912,7 +912,6 @@ bool blk_mq_disp
On Wed, 2017-01-18 at 13:32 -0800, Dan Williams wrote:
> On Wed, Jan 18, 2017 at 1:02 PM, Darrick J. Wong
> wrote:
> > On Wed, Jan 18, 2017 at 03:39:17PM -0500, Jeff Moyer wrote:
> > > Jan Kara writes:
> > >
> > > > On Tue 17-01-17 15:14:21, Vishal Verma wrote:
> > > > > Your note on the online
On Wed, Jan 18, 2017 at 1:02 PM, Darrick J. Wong
wrote:
> On Wed, Jan 18, 2017 at 03:39:17PM -0500, Jeff Moyer wrote:
>> Jan Kara writes:
>>
>> > On Tue 17-01-17 15:14:21, Vishal Verma wrote:
>> >> Your note on the online repair does raise another tangentially related
>> >> topic. Currently, if t
On 01/18/2017 11:55 AM, Omar Sandoval wrote:
> From: Omar Sandoval
>
> We always do an atomic clear_bit() right before we call sbq_wake_up(),
> so we can use smp_mb__after_atomic(). While we're here, comment the
> memory barriers in here a little more.
Thanks Omar, applied 1-2.
--
Jens Axboe
Jan Kara writes:
> On Tue 17-01-17 15:14:21, Vishal Verma wrote:
>> Your note on the online repair does raise another tangentially related
>> topic. Currently, if there are badblocks, writes via the bio submission
>> path will clear the error (if the hardware is able to remap the bad
>> locations
Slava Dubeyko writes:
>> Well, the situation with NVM is more like with DRAM AFAIU. It is quite
>> reliable
>> but given the size the probability *some* cell has degraded is quite high.
>> And similar to DRAM you'll get MCE (Machine Check Exception) when you try
>> to read such cell. As Vishal w
From: Omar Sandoval
We always do an atomic clear_bit() right before we call sbq_wake_up(),
so we can use smp_mb__after_atomic(). While we're here, comment the
memory barriers in here a little more.
Signed-off-by: Omar Sandoval
---
lib/sbitmap.c | 13 ++---
1 file changed, 10 insertions
From: Omar Sandoval
When we resize a struct sbitmap_queue, we update the wakeup batch size,
but we don't update the wait count in the struct sbq_wait_states. If we
resized down from a size which could use a bigger batch size, these
counts could be too large and cause us to miss necessary wakeups.
On Tue, Jan 17, 2017 at 09:25:33PM -0800, wi...@bombadil.infradead.org wrote:
> On Fri, Jan 13, 2017 at 05:20:08PM -0700, Ross Zwisler wrote:
> > We still have a lot of work to do, though, and I'd like to propose a
> > discussion
> > around what features people would like to see enabled in the com
On 01/18/2017 08:14 AM, Paolo Valente wrote:
> according to the function blk_mq_sched_put_request, the
> mq.completed_request hook seems to always be invoked (if set) for a
> request for which the mq.put_rq_priv is invoked (if set).
Correct, any request that came out of blk_mq_sched_get_request()
> Il giorno 17 gen 2017, alle ore 11:49, Paolo Valente
> ha scritto:
>
> [NEW RESEND ATTEMPT]
>
>> Il giorno 17 gen 2017, alle ore 03:47, Jens Axboe ha scritto:
>>
>> On 12/22/2016 08:28 AM, Paolo Valente wrote:
>>>
Il giorno 19 dic 2016, alle ore 22:05, Jens Axboe ha
scritto:
>
Hi, Jens,
Jens Axboe writes:
> I like the change, hate the naming. I'd prefer one of two things:
>
> - Add bio_endio_complete() instead. That name sucks too, the
> important part is flipping the __name() to have a trace
> version instead.
ITYM a notrace version. By default, we want tracing
On 01/18/2017 04:16 PM, Johannes Thumshirn wrote:
> On Wed, Jan 18, 2017 at 05:14:36PM +0200, Sagi Grimberg wrote:
>>
>>> Hannes just spotted this:
>>> static int nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
>>> const struct blk_mq_queue_data *bd)
>>> {
>>> [...]
>>>__n
On Wed, Jan 18, 2017 at 5:40 PM, Sagi Grimberg wrote:
>
>> Your report provided this stats with one-completion dominance for the
>> single-threaded case. Does it also hold if you run multiple fio
>> threads per core?
>
>
> It's useless to run more threads on that core, it's already fully
> utilize
On Wed, Jan 18, 2017 at 05:14:36PM +0200, Sagi Grimberg wrote:
>
> >Hannes just spotted this:
> >static int nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
> > const struct blk_mq_queue_data *bd)
> >{
> >[...]
> >__nvme_submit_cmd(nvmeq, &cmnd);
> >nvme_process_cq
Hannes just spotted this:
static int nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
const struct blk_mq_queue_data *bd)
{
[...]
__nvme_submit_cmd(nvmeq, &cmnd);
nvme_process_cq(nvmeq);
spin_unlock_irq(&nvmeq->q_lock);
return BLK_MQ_RQ_QUEUE_OK;
On Wed, Jan 18, 2017 at 04:27:24PM +0200, Sagi Grimberg wrote:
>
> >So what you say is you saw a consomed == 1 [1] most of the time?
> >
> >[1] from
> >http://git.infradead.org/nvme.git/commitdiff/eed5a9d925c59e43980047059fde29e3aa0b7836
>
> Exactly. By processing 1 completion per interrupt it m
Your report provided this stats with one-completion dominance for the
single-threaded case. Does it also hold if you run multiple fio
threads per core?
It's useless to run more threads on that core, it's already fully
utilized. That single threads is already posting a fair amount of
submission
On 01/18/2017 03:48 AM, Hannes Reinecke wrote:
> Nearly there.
> You're missing a 'blk_mq_start_hw_queues(q)' after
> blk_mq_unfreeze_queue(); without it the queue will stall after switching
> the scheduler.
Yes indeed, forgot that. Needed after the quiesce.
> Also what's quite suspicious is this
On Wed, Jan 18, 2017 at 5:27 PM, Sagi Grimberg wrote:
>
>> So what you say is you saw a consomed == 1 [1] most of the time?
>>
>> [1] from
>> http://git.infradead.org/nvme.git/commitdiff/eed5a9d925c59e43980047059fde29e3aa0b7836
>
>
> Exactly. By processing 1 completion per interrupt it makes perfe
So what you say is you saw a consomed == 1 [1] most of the time?
[1] from
http://git.infradead.org/nvme.git/commitdiff/eed5a9d925c59e43980047059fde29e3aa0b7836
Exactly. By processing 1 completion per interrupt it makes perfect sense
why this performs poorly, it's not worth paying the soft-ir
On 01/17/2017 05:50 PM, Sagi Grimberg wrote:
>
>> So it looks like we are super not efficient because most of the
>> times we catch 1
>> completion per interrupt and the whole point is that we need to find
>> more! This fio
>> is single threaded with QD=32 so I'd expect that we
On Tue, Jan 17, 2017 at 06:38:43PM +0200, Sagi Grimberg wrote:
>
> >Just for the record, all tests you've run are with the upper irq_poll_budget
> >of
> >256 [1]?
>
> Yes, but that's the point, I never ever reach this budget because
> I'm only processing 1-2 completions per interrupt.
>
> >We (
On 01/17/2017 02:00 PM, Jens Axboe wrote:
> On 01/17/2017 04:47 AM, Jens Axboe wrote:
>> On 01/17/2017 12:57 AM, Hannes Reinecke wrote:
>>> Hi Jens,
>>>
>>> I gave your latest patchset from
>>>
>>> git.kernel.dk/linux-block blk-mq-sched
>>>
>>> I see a kernel oops when shutting down:
>>>
>>> [ 2132
On Fri 16-12-16 08:44:11, Aneesh Kumar K.V wrote:
> Jerome Glisse writes:
>
> > I would like to discuss un-addressable device memory in the context of
> > filesystem and block device. Specificaly how to handle write-back, read,
> > ... when a filesystem page is migrated to device memory that CPU
On Tue 17-01-17 15:14:21, Vishal Verma wrote:
> Your note on the online repair does raise another tangentially related
> topic. Currently, if there are badblocks, writes via the bio submission
> path will clear the error (if the hardware is able to remap the bad
> locations). However, if the filesy
When scheduling workqueue elements the callback function might be called
directly, so holding the event lock is potentially dangerous as it might
lead to a deadlock:
[ 989.542827] INFO: task systemd-udevd:459 blocked for more than 480 seconds.
[ 989.609721] Not tainted 4.10.0-rc4+ #546
[
On Tue 17-01-17 15:37:05, Vishal Verma wrote:
> I do mean that in the filesystem, for every IO, the badblocks will be
> checked. Currently, the pmem driver does this, and the hope is that the
> filesystem can do a better job at it. The driver unconditionally checks
> every IO for badblocks on the w
On Tue, Jan 17, 2017 at 10:06:51PM +0200, Sagi Grimberg wrote:
>
>> @@ -1014,9 +1013,9 @@ static int nvme_rdma_map_data(struct nvme_rdma_queue
>> *queue,
>> }
>>
>
> Christoph, a little above here we still look at blk_rq_bytes(),
> shouldn't that look at blk_rq_payload_bytes() too?
The check
41 matches
Mail list logo