Skip to content
The methodOpen data
Back to the collection

Scheduler activations

Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, Henry M. Levy

1991 · Proceedings of the thirteenth ACM symposium on Operating systems principles

Other research
Read the paper
HN score
0
Mentions
4
Readers
4
Months
3
What’s in a score?

In the conversation

Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels

4 selected excerpts · 4 total mentions

rfoo
Neutral mention · rule
> work stealing executors have long been known to offer significantly lower latency with more consistent P99 than traditional threads. This has been known since forever - in the early 00s Well, we know how to make "traditional threads" fast, with lower latency and more consistent P99 since forever^2, in the early 90s. [1] Sure, we can't convince that Finnish guy this is worthwhile to include in THE kernel, despite similar ideas had been running in Google datacenters for idk how many years, 15 years+? But nothing stops us from doing it in the userspace, just as you said, a work stealing executor. And no, no coloring. Stack is all you need. Just make your "coroutines"…
Read the full comment
stackful. Done. All those attempts trying to be "zero-cost" and change programming model dramatically to avoid a stack, introduced much more overhead than a stack and a piece of decent context switch code. > You can tell async is directionally kind of correct in that io_uring is the kernel’s approach lol, it is very hard to model anything proactor like io_uring with async Rust due to its defects. [1] https://dl.acm.org/doi/10.1145/121132.121151
Original comment Async Rust never left the MVP state
twic
Neutral mention · rule
There isn't today, but there was in 1991, scheduler activations: https://dl.acm.org/doi/10.1145/121132.121151 The rough idea is that if the kernel blocks a thread on something like a page cache miss, then it notifies the program through something a bit like a signal handler; if the program is doing user-level scheduling, it can then take account of that thread being blocked. The actual mechanism in the paper is more refined than that.
Original comment How memory maps (mmap) deliver faster file access in Go
vacuity
Neutral mention · rule
Threads as they are conventionally considered are inadequate. Operating systems should offer something along the lines of scheduler activations[0]: a low-level mechanism that represents individual cores being scheduled/allocated to programs. Async is responsive simply because it conforms to the (asynchronous) nature of hardware events. Similarly, threads are most performant if leveraged according to the usage of hardware cores. A program that spawns 100 threads on a system with 10 physical cores is just going to have threads interrupting each other for no reason; each core can only do so much work in a time frame, whether it's running 1 thread or 10. The most…
Read the full comment
performant/efficient abstraction is a state machine[1] per core. However, for some loss of performance and (arguable) ease of development, threads can be used on top of scheduler activations[2]. Async on top of threads is just the worst of both worlds. Think in terms of the hardware resources and events (memory accesses too), and the abstractions write themselves. [0] https://en.wikipedia.org/wiki/Scheduler_activations, https://dl.acm.org/doi/10.1145/121132.121151 | Akin to thread-per-core [1] Stackless coroutines and event-driven programming [2] User-level virtual/green threads today, plus responsiveness to blocking I/O events
Original comment A comparison of Ada and Rust, using solutions to the Advent of Code
PaulDavisThe1st
Neutral mention · rule
We've been here before, (way) back in the 90s: "Scheduler activations: effective kernel support for the user-level management of parallelism" https://dl.acm.org/doi/10.1145/121132.121151 and also: "Adding Scheduler Activations to Mach 3.0" https://dada.cs.washington.edu/research/tr/1992/08/UW-CSE-92... People put a lot of time into thinking and researching this sort of thing. It even made it into Solaris. For one reason or another (possibly a lack of sufficient hardware parallelism) it never really gained much traction. Another critical issue to solve is that to do this "properly" (at least based on our model of this from the 90s), you have to have a re-entrant context switch routine, which is an interesting challenge.
Original comment Writing a scheduler for Linux in Rust that runs in user-space

Keep following the thread.

More in Other research

More from the same topics.