From: Brian King <brking@linux.vnet.ibm.com>
To: "Matthew R. Ochs" <mrochs@linux.vnet.ibm.com>,
"Manoj N. Kumar" <manoj@linux.vnet.ibm.com>
Cc: linux-scsi@vger.kernel.org,
James.Bottomley@HansenPartnership.com, nab@linux-iscsi.org,
Christoph Hellwig <hch@infradead.org>,
Michael Neuling <mikey@neuling.org>,
Ian Munsie <imunsie@au1.ibm.com>
Subject: Re: [PATCH v5] cxlflash: Base support for IBM CXL Flash Adapter
Date: Tue, 09 Jun 2015 13:30:37 -0500 [thread overview]
Message-ID: <557730CD.3020601@linux.vnet.ibm.com> (raw)
In-Reply-To: <DA7C290F-87F7-4741-B7EC-E06AE8B8741E@linux.vnet.ibm.com>
On 06/09/2015 11:01 AM, Matthew R. Ochs wrote:
> Brian/Manoj,
>
> See my alternate proposal below.
>
> -matt
>
> On Jun 9, 2015, at 9:37 AM, Manoj Kumar wrote:
>> On 6/9/2015 6:29 AM, Brian King wrote:
>>>>
>>>> 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.
>>
>> Good suggestion. Will atomic64_set(&afu->room, 1), if we exhaust retries in both legs.
>
> While I agree this will work it seems a bit of a kludge.
>
> What if we instead take advantage of our existing work queue and create a new work item that
> simply MMIO reads and atomically sets afu->room? With this, instead of slamming in a 1 to
> satisfy our logic such that a subsequent command will MMIO read, we would schedule the new
> work item and let afu->room be updated with a real value from the card.
>
> The only downside I see with this approach is that it has the potential to relax the window of time
> that we're 'down' (no room) and sending back busy...although that might not be such a bad thing
> if we were to get into this condition.
Seems reasonable. Would be simpler. I assume you then just schedule the work from cxlflash_send_cmd and
just return SCSI_MLQUEUE_HOST_BUSY from cxlflash_send_cmd if you don't have room?
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
next prev parent reply other threads:[~2015-06-09 18:30 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
2015-06-09 14:37 ` Manoj Kumar
2015-06-09 16:01 ` Matthew R. Ochs
2015-06-09 18:30 ` Brian King [this message]
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=557730CD.3020601@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.