-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SIMD metadata in /proc on Linux #16530
Conversation
Too many times, people's performance problems have amounted to "somehow your SIMD support isn't working", and determining that at runtime is difficult to describe to people. This adds a /proc/spl/kstat/zfs/simd node, which exposes metadata about which instructions ZFS thinks it can use, on AArch64 and x86_64 Linux, to make investigating things like this much easier. Signed-off-by: Rich Ercolani <[email protected]>
Cute, I think I dropped a cleanup commit in the rebase removing things like "shut up". Oops. I'll fix it when I inevitably end up pushing again to address someone's comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will definitely be handy. Some feedback inline and I see you accidentally included an unrelated draidcfg.gz
file in this PR.
The new CI GitHub actions workflows were merged so if you rebase this on master you'll get FreeBSD builds again. Don't be surprised to see some unrelated failures though.
It would be even better to show implementations selected in addition to CPU SIMD features, i.e., are we using the generic C version or optimized assembly for blake3, aes, sha256, etc? |
I'd prefer to have that as a separate feature, I think. This was intended to make it not require kernel patching to answer questions about "does our code at runtime think you're missing this thing", and trying to expose all the different _impl tunable values in one place would, to do "right", involve a bunch of boilerplate reworking to have them all handle it in a consistent abstraction and then teaching something to serialize that abstraction, and I'd rather not block "I would like to not have to ask people to apply a kernel patch as a first step in debugging" on that. |
Signed-off-by: Rich Ercolani <[email protected]>
Signed-off-by: Rich Ercolani <[email protected]>
It's not entirely comprehensive but the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I went ahead and resubmitted the failed CI run although it looks like it may take a while to run.
I'm not sure what happened here with the zfs-qemu runners but it did run cleanly on the zfs-linux ubuntu runners. Merged. |
Too many times, people's performance problems have amounted to "somehow your SIMD support isn't working", and determining that at runtime is difficult to describe to people. This adds a /proc/spl/kstat/zfs/simd node, which exposes metadata about which instructions ZFS thinks it can use, on AArch64 and x86_64 Linux, to make investigating things like this much easier. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#16530
Too many times, people's performance problems have amounted to "somehow your SIMD support isn't working", and determining that at runtime is difficult to describe to people. This adds a /proc/spl/kstat/zfs/simd node, which exposes metadata about which instructions ZFS thinks it can use, on AArch64 and x86_64 Linux, to make investigating things like this much easier. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#16530
Not sure it's working as intended.
That's all I see. This is a boring ubuntu22 x64 box:
|
Cute. Let me see what's going on, because it was working on x86_64. Of course, I wouldn't be surprised if Ubuntu broke something again...which kernel, specifically? |
Ah, I see, I broke the x86_64 part when fixing something at some point, apparently. Good job, me. Simple enough fix, I think... |
Confirmed working now, thanks! |
Too many times, people's performance problems have amounted to "somehow your SIMD support isn't working", and determining that at runtime is difficult to describe to people. This adds a /proc/spl/kstat/zfs/simd node, which exposes metadata about which instructions ZFS thinks it can use, on AArch64 and x86_64 Linux, to make investigating things like this much easier. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#16530
Too many times, people's performance problems have amounted to "somehow your SIMD support isn't working", and determining that at runtime is difficult to describe to people.
This adds a /proc/spl/kstat/zfs/simd node, which exposes metadata about which instructions ZFS thinks it can use, on AArch64 and x86_64 Linux, to make investigating things like this much easier.
e.g.
Motivation and Context
Things like #16452 where we got to patch a printk for similar functionality in to determine runtime state.
Description
Added a new /proc/spl/kstat/zfs/simd, which should print empty on other platforms and the various state checks on x86_64/arm/aarch64 Linux. (Since FreeBSD isn't a hostile upstream, this shouldn't be necessary to expose there...)
How Has This Been Tested?
I tried running it on a couple of x86_64 and aarch64 Linux boxes.
Notably, my machine with FreeBSD VMs is inaccessible at the moment, so I'd appreciate it if someone could try building it there if they get a chance before I make a new one...
Types of changes
Checklist:
Signed-off-by
.