Generic voting mechanism to build on top PM QoS
summary
Proposal builds a generic kernel voting subsystem that aggregates kernel and userspace ballots, exposes a planned /dev user interface, and auto-cleans votes when a process exits. Each ballot instantiates a ballot with policy (min/max, weighted, ranked) and returns a single winner; policies define units (mW, kbps, perf level). It supports a dictatorial/critical vote that overrides others. Targeted uses: cooling devices, interconnect bandwidth, and PM QoS composition.
AI-written summary · about
chapters (17)
- 0:00Introduction to voting mechanism
- 1:29Need for aggregation and voting
- 3:35Proposal for generic voting subsystem
- 5:07Use cases for voting mechanism
- 7:15Abstract nature of voting values
- 10:47Policy and unit selection
- 11:36Critical and dictatorial votes
- 13:28Subsystem integration with ballots
- 16:43Static configuration for dictatorial votes
- 17:05Potential applications in interconnect
- 18:12Skepticism about generic library approach
- 19:17User space interface importance
- 20:00Concrete use cases for user space voting
- 21:07Current QoS limitations
- 22:11Separating interface from voting logic
- 24:02Two separate design considerations
- 25:49Next steps and patch submission
related talks
25mLinux needs a Scheduler QOS API -- and it isn't nice(2)
40mVisions for the Linux Kernel PWM Subsystem- 40mVisions for the Linux Kernel PWM Subsystem
26mHardware Assisted PMU Virtualization
26mMulti-KVM Abstract
41mLinux Power Management Features & Their Interactions, Part 2
16mUnifying KVM API for protected VM and utilities
26mCooperative DMA in a memory-oversubscribed environment