On 2024/9/10 12:45, Damien Le Moal wrote:
On 9/10/24 10:09 AM, yangxingui wrote:
On 2024/9/9 21:21, Damien Le Moal wrote:
On 9/9/24 22:10, yangxingui wrote:
Hello axboe & John,
After the driver exposes all HW queues to the block layer, non-NCQ
commands will never be executed while fio is continuously running, such
as a smartctl command.
The cause of the problem is that other hctx used by the NCQ command is
still active and can continue to issue NCQ commands to the sata disk.
And the pio command keeps retrying in its corresponding hctx because
qc_defer() always returns true.
hctx0: ncq, pio, ncq
hctx1：ncq, ncq, ...
...
hctxn: ncq, ncq, ...
Is there any good solution for this?
SATA devices are single queue so how can you have multiple queues ?
What adapter are you using ?
In the following patch, we expose the host's 16 hardware queues to the block
layer. And when connecting to a sata disk, 16 hctx are used.
8d98416a55eb ("scsi: hisi_sas: Switch v3 hw to MQ")
OK, so the HBA is a hisi one, using libsas...
What is the device ? An SSD ? and HDD ?
Both SATA SSD and SATA HDD have this problem.
Do you set a block I/O scheduler for the drive, e.g. mq-deadline. If not, does
setting a scheduler resolve the issue ?
Currently, the default configuration mq-deadline is used, and the same
phenomenon occurs when I try setting it to none. It seems to have
nothing to do with the scheduling strategy.
I do not have any hisi HBA. I use a lot of mpt3sas and mpi3mr HBAs which also
have multiple queues with a shared tagset. Never seen the issue you are
reporting though using HDDs with mq-deadline or bfq as the scheduler.
Unlike libsas, as these hosts don't use qc_defer()?
Thanks,
Xingui
.
