On 28/09/2022 02:35, Yu Kuai wrote:
However both 5.15 stable and 5.19 mainline include fce54ed02757 - it
was automatically backported for 5.15 stable. Please double check that.
And can you also check performance there for those kernels?
I'm pretty sure io split can decline performance, especially for HDD,
because blk-mq can't guarantee that split io can be dispatched to disk
sequentially. However, this is usually not common with proper
max_sectors_kb.
Here is an example that if max_sector_kb is 128k, performance will
drop a lot under high concurrency:
https://lore.kernel.org/all/20220408073916.1428590-1-yukuai3@xxxxxxxxxx/
This never got merged in any form, right?
Here I set max_sectors_kb to 128k manually, and 1m random io performance
will drop while io concurrency increase:
| numjobs | v5.18-rc1 |
| ------- | --------- |
| 1 | 67.7 |
| 2 | 67.7 |
| 4 | 67.7 |
| 8 | 67.7 |
| 16 | 64.8 |
| 32 | 59.8 |
| 64 | 54.9 |
| 128 | 49 |
| 256 | 37.7 |
| 512 | 31.8 |
Commit fce54ed02757 was to circumvent a terrible performance hit for
IOMMU enabled from 4e89dce72521 - have you ever tested with IOMMU
enabled?
I understand that fce54ed02757 fix a terrible performance regression,
and I'm not familiar with IOMMU and I never test that.
If fce54ed02757 really does cause a performance regression in some
scenarios, then we can consider reverting it from any stable kernel
and also backporting [0] when it is included in Linus' kernel
That sounds good.
For 5.10 stable, I think it's ok to revert it for now, and if someone
cares about the problem 4e89dce72521 fixed, they can try to backport it
together with follow up patches.
For 5.10 stable revert only,
Reviewed-by: John Garry <john.garry@xxxxxxxxxx>
Thanks,
John
