On 3/25/24 23:22, Christoph Hellwig wrote:
On Mon, Mar 25, 2024 at 03:14:19PM -0700, Bart Van Assche wrote:
On my test setup (x86 VM with 72 CPU cores) this patch results in 2.9% more
IOPS. IOPS have been measured as follows:
$ modprobe null_blk nr_devices=1 completion_nsec=0
$ fio --bs=4096 --disable_clat=1 --disable_slat=1 --group_reporting=1 \
--gtod_reduce=1 --invalidate=1 --ioengine=psync --ioscheduler=none \
--norandommap --runtime=60 --rw=randread --thread --time_based=1 \
--buffered=0 --numjobs=64 --name=/dev/nullb0 --filename=/dev/nullb0
And how does it behave when you have multiple request_queues sharing
a tag_set with very unevent use that could cause one to starve all
the tags? Because that is what this code exists for.
Hi Christoph,
The proposed test case block/035 includes the following test:
* Create a first request queue with completion time 1 ms and queue
depth 64.
* Create a second request queue with completion time 100 ms and that
shares the tag set of the first request queue.
* Submit I/O to both request queues.
If I run that test I see a queue depth of about 60 for the second
request queue and a queue depth of about 4 for the first request queue.
This shows that both request queues make sufficient progress. This is
because of the fairness algorithms in the sbitmap code.
Given the performance impact of the request queue fairness algorithm, I
propose that users who need better fairness than what can be realized
with the sbitmap algorithms enable a cgroup policy of their preference.
See also
https://github.com/osandov/blktests/compare/master...bvanassche:blktests:master.
Thanks,
Bart.
