gpiolib: Avoid the hotplug performance reduction#6862
Merged
Conversation
The 6.9 kernel introduced a large patchset [1] designed to make gpiochip usage safe in the presence of potential hotplugging events. The changes included protecting every gpiochip access with a claim of an interlock. Running on a Pi 5 these changes reduce GPIO performance from userspace by around 10%. The penalty would be proportionally higher from kernel, as seen by SPI speed reductions. Patch the gpiolib implementation to remove the protection of gpiochip accesses. By providing alternative implementations of the relevant macros, the changes are localised and therefore easier to verify. See: raspberrypi#6854 [1] https://lwn.net/Articles/960024/ Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Contributor
Author
|
Here are the results of running a performance test on a Pi 5. The test drives a GPIO high and low 1 million times in a tight loop, repeating the process 10 times and calculating the mean and standard deviation of the per-pass execution time (in microseconds): You can see that there is still a small performance regression with the patched kernel, but it has been reduced from ~11% to less than 1%. |
Contributor
Author
|
This seems like a step in the right direction for performance. |
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
May 21, 2025
kernel: usb: xhci: set Input Slot Context bit in xhci_fixup_endpoint See: raspberrypi/linux#6850 kernel: configs: Enable more MediaTek drivers See: raspberrypi/linux#6857 kernel: firmware/raspberrypi: raise timeout to 3s See: raspberrypi/linux#6859 kernel: overlays: sc16is75x: Disable spidev0 first See: raspberrypi/linux#6858 kernel: gpiolib: Avoid the hotplug performance reduction See: raspberrypi/linux#6862
popcornmix
added a commit
to raspberrypi/rpi-firmware
that referenced
this pull request
May 21, 2025
kernel: usb: xhci: set Input Slot Context bit in xhci_fixup_endpoint See: raspberrypi/linux#6850 kernel: configs: Enable more MediaTek drivers See: raspberrypi/linux#6857 kernel: firmware/raspberrypi: raise timeout to 3s See: raspberrypi/linux#6859 kernel: overlays: sc16is75x: Disable spidev0 first See: raspberrypi/linux#6858 kernel: gpiolib: Avoid the hotplug performance reduction See: raspberrypi/linux#6862
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



The 6.9 kernel introduced a large patchset [1] designed to make gpiochip usage safe in the presence of potential hotplugging events. The changes included protecting every gpiochip access with a claim of an interlock.
Running on a Pi 5 these changes reduce GPIO performance from userspace by around 10%. The penalty would be proportionally higher from kernel, as seen by SPI speed reductions.
Patch the gpiolib implementation to remove the protection of gpiochip accesses. By providing alternative implementations of the relevant macros, the changes are localised and therefore easier to verify.
See: #6854
[1] https://lwn.net/Articles/960024/