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@huawei.com/
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@huawei.com
Thanks, John