The problem
What’s missing when a scheduler is told that a thread is runnable but not what that thread is trying to accomplish?
What current research shows
Linux exposes signals such as runnable state, utilization history, affinity, wakeups, priorities, and cgroup controls. Those signals are useful, but they’re not a complete description of request identity, data sharing, cache lifetime, latency importance, or device dependency. Linux's utilization-clamp interface explicitly gives user space a way to provide performance requirements because the scheduler can’t infer every requirement from history alone.
Where the evidence stops
This is an information-boundary study, not proof that a new policy will outperform the default scheduler. Workload metadata can be stale, expensive to collect, wrong, or unsafe to expose.
What Valen Systems is testing
Measure whether explicit dependency and latency metadata improves placement or energy without adding enough coordination overhead to erase the gain.