On 5/23/22 1:59 PM, Jens Axboe wrote: >> And from a maintenenace standpoint, I really think it would be good to >> try to try to walk away from those "case IORING_OP_xyz" things, and >> try to split things up into more manageable pieces. >> >> Hmm? > > As mentioned, it's something that I have myself been thinking about for > the past few releases. It's not difficult work and can be done in a > sequential kind of manner, but it will add some pain in terms of > backports. Nothing _really_ major, but... Longer term it'll be nicer for > sure, which is the most important bit. > > I've got some ideas on how to split the core bits, and the > related-op-per file kind of idea for the rest makes sense. Eg net > related bits can go in one, or maybe we can even go finer grained and > (almost) do per-op. > > I'll spend some time after the merge window to try and get this sorted > out. Well I spent some time yesterday, and 53 patches later, I think it looks pretty sane. At this point everything is split out, except read/write and poll handling. There's still some things we can split out, like the io_uring_register() side, but as it stands, ~35% of the code has been split into separate files for either opcodes or infrastructure that goes together. We can definitely get this down further, but it's a good start. Anyway, I pitted -git vs -git + this merged in, to test with and without spectre mitigations as we now have an indirect ->prep() and ->issue() for each opcode in the fast path. I ran my usual peak testing, which is basically just polled async random reads from 3 devices. The box in question is a 12900K, so recent cpu. Mitigation status: /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: eIBRS with unprivileged eBPF Out of 5 runs, here are the results: -git, RETPOLINE=n, mitigations=off Maximum IOPS=12837K Maximum IOPS=12812K Maximum IOPS=12834K Maximum IOPS=12856K Maximum IOPS=12809K for-5.20/io_uring, RETPOLINE=n, mitigations=off Maximum IOPS=12877K Maximum IOPS=12870K Maximum IOPS=12848K Maximum IOPS=12837K Maximum IOPS=12899K -git, RETPOLINE=y, mitigations=on Maximum IOPS=12869K Maximum IOPS=12766K Maximum IOPS=12817K Maximum IOPS=12866K Maximum IOPS=12828K for-5.20/io_uring, RETPOLINE=y, mitigations=on Maximum IOPS=12859K Maximum IOPS=12921K Maximum IOPS=12899K Maximum IOPS=12859K Maximum IOPS=12904K If anything, the new code seems a smidge faster for both mitigations=off vs RETPOLINE=y && mitigations=on. Hmm? But at least from a first test this is promising and it may be a viable path forward to make it a bit saner. If you're curious, git tree here: https://git.kernel.dk/cgit/linux-block/log/?h=for-5.20/io_uring with the first 5 patches being staged for 5.19 as well as they are just consistency cleanups. -- Jens Axboe
