Hi Martin, >> Please read what I proposed. megaraid VDs don't report QUEUE_FULL so you would not trigger the device_busy counter. Yes, megaraid does not use set track_queue_depth, and never reports QUEUE_FULL . Instead of relying on QUEUE_FULL and some complex heuristics of when to start tracking device_busy, why can't we simply use " track_queue_depth" ( along with the other flag that Ming added) to decide which devices need queue depth tracking, and track device_busy only for them? >>Something like not maintaining device_busy until we actually get a >>QUEUE_FULL condition. And then rely on the existing queue depth ramp up >>heuristics to determine when to disable the busy counter again. I am not sure how we can suddenly start tracking device_busy on the fly, if we do not know how many IO are already pending for that device? Won't device_busy have a high chance of getting negative ( or at least wrong value) when pending IOs start getting completed? Thanks, Sumanesh -----Original Message----- From: Martin K. Petersen <martin.petersen@xxxxxxxxxx> Sent: Thursday, January 23, 2020 6:59 PM To: Sumanesh Samanta <sumanesh.samanta@xxxxxxxxxxxx> Cc: linux-scsi@xxxxxxxxxxxxxxx; Martin K. Petersen <martin.petersen@xxxxxxxxxx> Subject: Re: [PATCH 5/6] scsi: core: don't limit per-LUN queue depth for SSD when HBA needs Sumanesh, > The high-end controllers might expose a SCSI interface, but can have > all kind of devices (NVMe/SCSI/SATA) behind it, and has its own > capability to queue IO and feed to devices as needed. Those devices > should not be penalized with the overhead of the device_busy counter, > just because they chose to expose themselves has SCSI devices (for > historical and backward compatibility reasons). Please read what I proposed. megaraid VDs don't report QUEUE_FULL so you would not trigger the device_busy counter. -- Martin K. Petersen Oracle Linux Engineering
