All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Ming Lei <ming.lei@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Jeff Moyer <jmoyer@redhat.com>, Mike Snitzer <snitzer@redhat.com>
Subject: Re: [PATCH V2 2/4] blk-mq: fix shared queue mapping
Date: Mon, 17 Dec 2018 11:57:25 +0100	[thread overview]
Message-ID: <20181217105725.GA5826@lst.de> (raw)
In-Reply-To: <20181217104248.5828-3-ming.lei@redhat.com>

On Mon, Dec 17, 2018 at 06:42:46PM +0800, Ming Lei wrote:
> From: Christoph Hellwig <hch@lst.de>
> 
> Even though poll_queues are zero, nvme's mapping for HCTX_TYPE_POLL still
> may be setup via blk_mq_map_queues() which cause different mapping compared
> with HCTX_TYPE_DEFAULT's mapping built from managed irq affinity.
> 
> This mapping will cause hctx->type to be over-written in blk_mq_map_swqueue(),
> then the whole mapping may become broken, for example, one same ctx can be
> mapped to different hctxs with same hctx type. This bad mapping has caused
> IO hang in simple dd test, as reported by Mike.
> 
> This patch sets map->nr_queues as zero explictly if there is zero
> queues for such queue type, also maps to correct hctx if .nr_queues of the
> queue type is zero.
> 
> Cc: Jeff Moyer <jmoyer@redhat.com>
> Cc: Mike Snitzer <snitzer@redhat.com>
> Cc: Christoph Hellwig <hch@lst.de>
> 
> (don't handle zero .nr_queues map in blk_mq_map_swqueue())
> Signed-off-by: Ming Lei <ming.lei@redhat.com>

I actually think we should split this into three patches:

 1) skip zero-queue maps in blk_mq_map_swqueue
 2) skip zero-queue maps in blk_mq_map_queue
 3) don't duplicate maps in nvme

sorry for misleading you with my quick WIP patch.

I can send send patches for my two with a proper changelogs, but
I'll leave blk_mq_map_swqueue to you as I don't full understand
the rationale, even if it looks sensible to me.

  reply	other threads:[~2018-12-17 10:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-17 10:42 [PATCH V2 0/4] blk-mq: queue mapping fix & improvement Ming Lei
2018-12-17 10:42 ` [PATCH V2 1/4] blk-mq: fix allocation for queue mapping table Ming Lei
2018-12-17 10:42 ` [PATCH V2 2/4] blk-mq: fix shared queue mapping Ming Lei
2018-12-17 10:57   ` Christoph Hellwig [this message]
2018-12-17 11:06     ` Ming Lei
2018-12-17 10:42 ` [PATCH V2 3/4] blk-mq: fix dispatch from sw queue Ming Lei
2018-12-17 11:08   ` Christoph Hellwig
2018-12-17 11:15     ` Ming Lei
2018-12-17 11:16       ` Christoph Hellwig
2018-12-17 10:42 ` [PATCH V2 4/4] blk-mq: export hctx->type in debugfs instead of sysfs Ming Lei
2018-12-17 10:57   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181217105725.GA5826@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=jmoyer@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=snitzer@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.