> From: Martin K. Petersen <martin.petersen@xxxxxxxxxx> > Sent: Tuesday, October 12, 2021 2:28 PM > To: Dexuan Cui <decui@xxxxxxxxxxxxx> > > > Regarding this patch, I'm not sure if it's a "workaround": if it's > > incorrect to set a bigger-than-SHRT_MAX scsi_driver.can_queue value, > > probably we should change scsi_driver.can_queue from "int" to "u16"? > > > BTW, I guess the "cmd_per_lun" should also be "u16" rather than > > "short"? > > I agree that it would be nice to get all this cleaned up. Several, > somewhat peculiar, 25-year old design choices. > > cmd_per_lun has traditionally been in the ballpark of low hundreds, > can_queue typically in the low thousands. And the block layer currently > caps at ~10K. Happy to take patches fixing this up, although I am a bit > worried about how much churn it will generate. Thanks for the explanation! > That said, I do think that cleaning this up is somewhat orthogonal to > the issue with storvsc. I suspect that allowing a huge amount of > concurrent outstanding commands is going to be detrimental to > performance for most workloads. And from that perspective I think that > the short->int fix, while valid given the type discrepancy, is just > treating the symptom. Agreed. > Therefore I consider the short->int fix a workaround. And the proper fix > involves looking closely at things are scaled in the storvsc case. Which > I have noted that Michael is working on. Agreed. My v1 actually tried to work around the storvsc driver instread. :-)
