On 5/26/21 11:54 PM, Hannes Reinecke wrote: > On 5/27/21 3:01 AM, Bart Van Assche wrote: >> For interactive workloads it is important that synchronous requests are >> not delayed. Hence reserve 25% of tags for synchronous requests. This patch >> still allows asynchronous requests to fill the hardware queues since >> blk_mq_init_sched() makes sure that the number of scheduler requests is the >> double of the hardware queue depth. From blk_mq_init_sched(): >> >> q->nr_requests = 2 * min_t(unsigned int, q->tag_set->queue_depth, >> BLKDEV_MAX_RQ); > > I wonder if that's a good idea in general ... I'm thinking of poor SATA > drives which only have 31 tags; setting aside 8 of them for specific > use-cases does make a difference one would think. > > Do you have testcases for this? Hi Hannes, The mq-deadline scheduler is the only scheduler that does not yet set aside tags for synchronous requests. BFQ and Kyber both implement the .limit_depth I/O scheduler callback function. Yes, I have a test case for this, namely SCSI UFS devices. The UFS device in my test setup supports a single I/O queue and limits the number of outstanding SCSI commands to 32 (UFSHCD_CAN_QUEUE). Please note that the limit mentioned above is still above the number of controller tags. For e.g. UFS q->tag_set->queue_depth == 32 and attaching an I/O scheduler increases nr_requests from 32 to 64. Reserving 25% of tags for synchronous requests leaves 3 * 64 / 4 = 48 scheduler tags for asynchronous requests. Thanks, Bart.
