Re: [GIT PULL] io_uring xattr support

[Jens Axboe <axboe@kernel.dk>]

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