Brian: Thanks for the quick review. Comments below.
- Manoj 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.
+ + 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.
+ 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)I'm guessing you'd want the udelay here as well.
Same reason as the queuecommand issue above. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
