quoted

Do we have any performance figures to say that the effect is negligible?

I ran this through my usual peak testing, it's pretty good at finding
any changes in performance related to changes in overhead. The workload
is a pretty simple 512b random read, QD 128, using io_uring and polled
IO.

It seems to cause a slight slowdown for me. Performance before the patch
is around 3.23-3.27M IOPS, and after we're at around 3.20-3.22. Looking
at perf diff, the most interesting bits seem to be:


2.09%     -1.05%  [kernel.vmlinux]  [k] blk_mq_get_tag
0.48%     +0.98%  [kernel.vmlinux]  [k] __do_sys_io_uring_enter
1.49%     +0.85%  [kernel.vmlinux]  [k] __blk_mq_alloc_request
           +0.71%  [kernel.vmlinux]  [k] __blk_mq_free_request

which seems to show some shifting around of cost (often happens), but
generally up a bit looking at the blk side.

So nothing really major here, and I don't think it's something that
should getting this fixed.

John, I can run your series through the same,
let me know.

The first patch in my series solves the issues reported by community also:
https://lore.kernel.org/linux-block/1614957294-188540-2-git-send-email-john.garry@huawei.com/ (local)

And that patch should give no throughput performance hit.

The other two patches in that series are to solve more theoretical 
issues of iterator interactions, but their approach is unacceptable.

Obviously your call. IMHO, Bart's solution would make more sense.

Thanks,
John