From: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Brian King <brking@linux.vnet.ibm.com>,
Douglas Miller <dougmill@linux.vnet.ibm.com>,
linux-block@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH v2 1/2] blk-mq: Fix failed allocation path when mapping queues
Date: Thu, 01 Dec 2016 15:51:37 -0200 [thread overview]
Message-ID: <8737i7sfkm.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1479837269-5742-1-git-send-email-krisman@linux.vnet.ibm.com> (Gabriel Krisman Bertazi's message of "Tue, 22 Nov 2016 15:54:28 -0200")
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> writes:
> My one concern about this patch is if remapping an arbitrary queue to
> hctx_0 could result in outstanding requests getting submitted to the
> wrong hctx. I couldn't observe this happening during tests, but I'm not
> entirely sure it'll never happen. I believe the queue will be empty if
> we are trying to allocate tags for it, unless it was using another alive
> hctx queue and for some reason got reassigned to this new hctx. is this
> possible at all?
I no longer believe this case to be an issue for accepting this patch,
since if a queue enters this path and get's remapped to hctx_0, it means
the ctx would already be getting remaped to a new queue anyway, and it
should use the requests that were just mapped for that queue. So, for a
correctness standpoint it doesn't matter which queue we are remaping,
the failed hctx or hctx_0, no request would get redirected to the wrong
queue with this change.
Jens, do you think this set is good for merging in 4.10? It fixes some
issues for us on low memory conditions.
--
Gabriel Krisman Bertazi
prev parent reply other threads:[~2016-12-01 17:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 17:54 [PATCH v2 1/2] blk-mq: Fix failed allocation path when mapping queues Gabriel Krisman Bertazi
2016-11-22 17:54 ` [PATCH v2 2/2] blk-mq: Avoid memory reclaim when remapping queues Gabriel Krisman Bertazi
2016-12-01 17:51 ` Gabriel Krisman Bertazi [this message]
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=8737i7sfkm.fsf@linux.vnet.ibm.com \
--to=krisman@linux.vnet.ibm.com \
--cc=axboe@kernel.dk \
--cc=brking@linux.vnet.ibm.com \
--cc=dougmill@linux.vnet.ibm.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/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.