From: Brian King <brking@linux.vnet.ibm.com>
To: manoj@linux.vnet.ibm.com,
"Matthew R. Ochs" <mrochs@linux.vnet.ibm.com>,
linux-scsi@vger.kernel.org,
James.Bottomley@HansenPartnership.com, nab@linux-iscsi.org,
hch@infradead.org
Cc: mikey@neuling.org, imunsie@au1.ibm.com
Subject: Re: [PATCH v5] cxlflash: Base support for IBM CXL Flash Adapter
Date: Tue, 09 Jun 2015 06:29:38 -0500 [thread overview]
Message-ID: <5576CE22.1060409@linux.vnet.ibm.com> (raw)
In-Reply-To: <55762437.6060607@linux.vnet.ibm.com>
On 06/08/2015 06:24 PM, Manoj Kumar wrote:
> On 6/8/2015 5:56 PM, Brian King wrote:
>>> +retry:
>>> + newval = atomic64_dec_if_positive(&afu->room);
>>> + if (!newval) {
>>> + do {
>>> + room = readq_be(&afu->host_map->cmd_room);
>>> + atomic64_set(&afu->room, room);
>>> + if (room)
>>> + goto write_ioarrin;
>>> + } while (nretry++ < MC_ROOM_RETRY_CNT);
>>
>> It looks like you removed the udelay here. Was that intentional?
>
> Pulled out going to sleep in the queuecommand path.
udelay doesn't sleep, its a busy wait, so you can still use it in queuecommand,
just don't spend too much time, and its probably better to udelay then to
just re-read in a tight loop.
>
>>> +
>>> + pr_err("%s: no cmd_room to send 0x%X\n",
>>> + __func__, cmd->rcb.cdb[0]);
>>> + rc = SCSI_MLQUEUE_HOST_BUSY;
>>
>> If you actually get here, how do you get out of this state? Since now afu->room is
>> zero and anyone that comes through here will go to the else if leg.
>
> This was the optimization to avoid the MMIO for both threads. The other thread that raced should do the atomic set of afu->room to a positive value.
Let's take the simpler scenario of just one thread.
Let's start with afu->room = 1
We call atomic64_dec_if_positive, which results in afu->room going to zero and 0 being returned,
so we go into the if leg.
If afu->room is zero every time we read it from the adapter and we exhaust our retries,
we return SCSI_MLQUEUE_HOST_BUSY. However, the next time we enter cxlflash_send_cmd,
since afu->cmd is now 0, it will no longer get decremented, but the return value will
be -1, so we'll go down the else if leg. We'll never get into the if leg again to
re-read afu->room from the AFU. The simplest fix might just be to set afu->room = 1
if you ever leave the if leg without having room.
+ newval = atomic64_dec_if_positive(&afu->room);
+ if (!newval) {
+ do {
+ room = readq_be(&afu->host_map->cmd_room);
+ atomic64_set(&afu->room, room);
+ if (room)
+ goto write_ioarrin;
+ } while (nretry++ < MC_ROOM_RETRY_CNT);
+
+ pr_err("%s: no cmd_room to send 0x%X\n",
+ __func__, cmd->rcb.cdb[0]);
+ rc = SCSI_MLQUEUE_HOST_BUSY;
+ goto out;
+ } else if (unlikely(newval < 0)) {
+ /* This should be rare. i.e. Only if two threads race and
+ * decrement before the MMIO read is done. In this case
+ * just benefit from the other thread having updated
+ * afu->room.
+ */
+ if (nretry++ < MC_ROOM_RETRY_CNT)
+ goto retry;
+ else {
+ rc = SCSI_MLQUEUE_HOST_BUSY;
+ goto out;
+ }
+ }
>
>>> + goto out;
>>> + } else if (unlikely(newval < 0)) {
>>> + /* This should be rare. i.e. Only if two threads race and
>>> + * decrement before the MMIO read is done. In this case
>>> + * just benefit from the other thread having updated
>>> + * afu->room.
>>> + */
>>> + if (nretry++ < MC_ROOM_RETRY_CNT)
>>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
next prev parent reply other threads:[~2015-06-09 11:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 22:30 [PATCH v5] cxlflash: Base support for IBM CXL Flash Adapter Matthew R. Ochs
2015-06-08 22:56 ` Brian King
2015-06-08 23:24 ` Manoj Kumar
2015-06-09 11:29 ` Brian King [this message]
2015-06-09 14:37 ` Manoj Kumar
2015-06-09 16:01 ` Matthew R. Ochs
2015-06-09 18:30 ` Brian King
2015-06-09 18:52 ` Matthew R. Ochs
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=5576CE22.1060409@linux.vnet.ibm.com \
--to=brking@linux.vnet.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=hch@infradead.org \
--cc=imunsie@au1.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=manoj@linux.vnet.ibm.com \
--cc=mikey@neuling.org \
--cc=mrochs@linux.vnet.ibm.com \
--cc=nab@linux-iscsi.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.