Use of Netlink for thermal kernel-user notification is problematic
summary
Kernel thermal notifications use NETLINK_GENERIC and NETLINK_KOBJECT_UEVENT and are shown to fail under event storms: experiments reproduce a full system freeze when events arrive at about 1 ms storm intervals on machines with tens of thermal zones. NETLINK_KOBJECT_UEVENT causes udev to spawn many CPU-bound workers, inflating dynamic memory; netlink code still spends hundreds of cycles building messages when no listener exists. Measured user-space reaction latency is about 100 µs; filtering or per-subscriber groups are needed.
AI-written summary · about
chapters (7)
- 0:00Introduction and background
- 1:28Netlink usage on Intel platforms
- 3:18Performance and scalability issues
- 8:58User space governor and inefficiencies
- 10:49Netlink event handling problems
- 13:18Filtering and multicast group limitations
- 15:56Proposed solutions and next steps
related talks
31mBeware of the kernel RTNL mutex
30mNoisy Neighbors, through Networking
20mNetKernel: Making Network Stack Part of the Virtualized Infrastructure
34mCurrent state of netlink decoding in strace
32mMPTCP: Extending kernel functionality with eBPF and Netlink
44mAdvanced Linux Kernel Networking Monitoring
30mOn Sockets and System Calls: Minimizing Context Switches for the Socket API
19mThermal framework issues and limitations