https://www.phoronix.com/scan.php?page=news_item&px=Intel-Bus-Lock-Detection-2021
Intel's Bus Lock Detection Might Be Ready For The Mainline Linux Kernel
Written by Michael Larabel in Intel on 30 March 2021 at 07:05 AM EDT. 1 Comment
INTEL -- For longer than the past year Intel engineers have been working on wiring up the Linux kernel support to handle split lock detection and bus lock detection. Back in Linux 5.7 the split lock detection landed for warning or even killing the offending software should a split lock occur due to the significant performance impact and possible denial of service. Now it's looking like the bus lock detection code could be ready for mainline.
After the split lock detection code was merged, Intel engineers turned their focus to bus lock detection for Linux. Again, important due to the performance penalties and possible denial of service implications. Bus locks can disrupt the performance to other CPU cores and are much slower than an atomic operation happening within a cache line. Like the split lock detection, the bus lock detection relies upon the CPU being able to notify the kernel when a user instruction acquires a bus lock.
Yesterday tip/tip.git's x86/splitlock branch picked up these bus lock detection patches from Intel's Fenghua Yu. Thus assuming nothing major comes up, it's likely next to be sent in as a pull request as part of changes for Linux 5.13.
Whether a given CPU supports the bus lock detection will be exposed on future versions of the kernel by the new "bus_lock_detect" feature flag within /proc/cpuinfo.
The handling makes use of the same split_lock_detect= option introduced for the split lock handling. For the bus lock detection there are the options of doing nothing, warning once per task, killing the task by sending SIGBUS to user, or rate limiting the bus lock to a given number of times per second for non-root users. The default behavior with the patches on supported CPUs will be to just warn the user once per task to the kernel log.
See the latest documentation for more details on the split / bus lock detection for Linux.
Age Commit message (Expand) Author Files Lines
2021-05-18 Documentation/x86: Add ratelimit in buslock.rstx86-splitlock-2021-06-28x86/splitlock Fenghua Yu 1 -0/+22
2021-05-18 Documentation/admin-guide: Add bus lock ratelimit Fenghua Yu 1 -0/+8
2021-05-18 x86/bus_lock: Set rate limit for bus lock Fenghua Yu 1 -2/+40
2021-05-18 Documentation/x86: Add buslock.rst Fenghua Yu 2 -0/+105
Hi xiexiuqi, welcome to the openEuler Community.
I'm the Bot here serving you. You can find the instructions on how to interact with me at
https://gitee.com/openeuler/community/blob/master/en/sig-infrastructure/command.md.
If you have any questions, please contact the SIG: Kernel, and any of the maintainers: @Xie XiuQi, @YangYingliang, @成坚 (CHENG Jian).
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。
Support for enhanced split lock detection:
Newer CPUs provide a second mechanism to detect operations with lock
prefix which go accross a cache line boundary. Such operations have to
take bus lock which causes a system wide performance degradation when
these operations happen frequently.
The new mechanism is not using the #AC exception. It triggers #DB and is
restricted to operations in user space. Kernel side split lock access can
only be detected by the #AC based variant. Contrary to the #AC based
mechanism the #DB based variant triggers _after_ the instruction was
executed. The mechanism is CPUID enumerated and contrary to the #AC
version which is based on the magic TEST_CTRL_MSR and model/family based
enumeration on the way to become architectural.
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tag/?h=x86-splitlock-2021-04-26
登录 后才可以发表评论