Skip to content
Hallway
0:00 / 0:00

#user-levelthreads#m:nthreading#fibers

User-level threads....... with threads. - Paul Turner - Google

Linux Plumbers Conference

10K subscribers • 23 videos on Hallway • Conference channel

YouTube
  • Recommended by 6 people: 6 on Hacker News.
  • A classic. People kept recommending it from 2013 to 2021.
  • Presented by Paul Turner, Google

Advanced. Deep dive for people who know the field.

40K views13 years ago6 recommendations

Systems programmingOperating systemsConcurrency and parallelismPerformance and optimization

Paul Turner discusses Google's work on Linux kernel interfaces that enable fast, cooperative user-level scheduling of regular threads.

"Multi-threaded programming is hard. Synchronous interfaces can help, but typically require lighter-weight representation of concurrency than a thread to implement efficiently. Frustratingly, this leads to a proliferation of both asynchronous and synchronous interfaces, depending on the language used. Over the past year we've been looking at how a uniform, performant, synchronous programming model can be implemented across all of Google's core languages (C++, Java, Go, Python), while maintaining compatibility with existing code. In this talk I will discuss new kernel interfaces which allow the use of regular threads in a co-operative fashion, with under 200ns context-switch times, and how new user-level primitives built on top of this support." linuxplumbersconf.org/2013/

Why it's here

6 people recommend this

What people say. Highly recommended for its deep dive into cooperative native thread scheduling and the challenges of M:N threading models.

russell_hon Hacker News • Recommends

On “The Rust standard library no longer has any scheduling baked into it”

Paul Turner explained this really well at this year's Linux Plumbers Conference. The whole talk is fantastic, but the explanation of what pron is describing in particular (and how it could be improved) starts around 8:39: link to this video
View on Hacker News

skybrianon Hacker News • Recommends

On “The future of M:N threading”

If you're interested in this area you might like this talk from the Linux plumbers' conference: "Over the past year we've been looking at how a uniform, performant, synchronous programming model can be implemented across all of Google's core languages (C++, Java, Go, Python), while maintaining compatibility with existing code." link to this video
View on Hacker News

acconstaon Hacker News • Recommends

On “Asynchronous IO in Rust”

…tell, M:N threading has been thoroughly abandoned by Linux, but it might be worth revisiting given the horrendous I/O scaling of Linux kernel threads. I would imagine scheduling user threads cooperatively simplifies things a lot. Google has a very interesting talk about cooperative native thread scheduling, but they haven't upstreamed their code: link to this video And here's what linux devs are actually doing (it's underwhelming, something like 50% of what the hardware is capable of): link In the meantime, people who actually need the performance (HPC and even some enterprise servers) have to bypass the kernel entirely. It looks like that's going to be possible even in virtualized environments, tha…
View on Hacker News

asbon Hacker News • Recommends

On “Haskell in the Datacentre”

Related to this discussion, this talk on user-scheduled OS threads is really interesting. It's a shame no proposed implementation or experimental patches have appeared link to this video
View on Hacker News

lomnakkuson Hacker News • Recommends

On “Fast, Safe, and Complete(ish) Web Service in Rust”

Allow me to third that. It's one of dangers assuming that what you learned at university 15-20 years ago still applies. Another interesting talk: 0 (and even that is 5 years old) 0 link to this video
View on Hacker News

m0zgon Hacker News • Recommends

On “C++ Coroutines Do Not Spark Joy”

Google needs to get off its ass and open source Fibers (not to be confused with Google Fiber). Fibers sparked plenty of joy in me back when I was at Google. It's just a more dignified way of doing things with threads, IMO. Here's the talk which, unfortunately, does not show the higher level APIs I'm talking about: link to this video . If this were released today everyone would slap their foreheads and say "of course that's how it should be done". Google folks have already removed the obstacle in that direction by adding userspace switching to the kernel in recent kernel releases. Just go all the way now, and release the kraken. Last update I've seen on this is this article from June of this year: [link…
View on Hacker News

u/Ruskyin r/ProgrammingLanguages • Mentions

On “The value of M:N scheduling over 1:1 scheduling”

…ands. An interface that supports user-space scheduling might look like scheduler activations, or perhaps Windows' user-mode scheduling framework. The idea is that all system calls become essentially asynchronous, and the process itself is always in charge of resuming threads. Google once looked at getting something similar into the Linux kernel: link to this video As far as I can tell they gave up mostly because it's hard to do that backwards-compatibly- which is the same sort of problem users of Windows' fibers and UMS hit. I suspect things would go much better on a new kernel that started out that way, but obviously that's a hard sell.…
6View on Reddit

dbauppon Hacker News • Mentions

On “The future of M:N threading”

It's hinted at in the video linked in the email1: > Over the past year we've been looking at how a uniform, performant, synchronous programming model can be implemented across all of Google's core languages (C++, Java, Go, Python), while maintaining compatibility with existing code. link to this video
View on Hacker News

onedognighton Hacker News • Mentions

On “The future of M:N threading”

There is no User-Mode scheduling in the Linux Kernel to my knowledge, but the video1 mentioned the post describes Linux patches that add support for it. 1 link to this video
View on Hacker News

basculeon Hacker News • Mentions

On “This Week in Rust – Static linking, Win64”

They're actually talking about pursuing a "N:1" concurrency model (i.e. userland-managed coroutines in the kernel). See: link to this video
View on Hacker News

nostrademonson Hacker News • Mentions

On “An Opinionated Guide to Modern Java, Part 3: Web Development”

Relevant HN thread: link BTW, I wonder if Paul Turner's work on fibers will change this equation if/when it makes it into the production kernel. link to this video Google has had very promising initial results with it.
View on Hacker News

mpweiheron Hacker News • Mentions

On “An introduction to reactive programming”

…proach, especially in languages/systems like Erlang, and the freedom that very cheap threads give you. My first point was that you actually have much more of this freedom than most people are aware of, even with (comparatively) heavy kernel threads. For example, see the "Replace user threads with ... threads" by Paul Turned (Plumber's Conference): link to this video More on that point, I see a lot of user-threading/async craziness on clients such as iOS that would have been easily been handled by less than a dozen kernel threads, most of which would be sleeping most of the time anyhow. That's a number of kernel threads that is easily manageable and not particularly resource intensive. My second point i…
View on Hacker News

pronon Hacker News • Mentions

On “Why async fn in traits are hard”

…kernel level. The easy part is the cost of scheduling. The kernel must schedule threads with very different behaviors -- say, encoding a video or serving requests over a socket -- so it uses a scheduling algorithm that's a compromise for all uses. But we can let the language's runtime take the scheduling of kernel threads with something like this: link to this video The harder part is managing the memory required for the stack. Even on 64-bit systems, the OS can't shrink and grow stacks finely enough. For example, I don't think there's a hard requirement that, say, memory below the sp is never accessed, so the OS can't even be sure about how much of the stack is used and can't uncommit pages. But even…
View on Hacker News

Veservon Hacker News • Mentions

On “Ways of Implementing a System Call”

Although you are technically correct in that the cost of system calls on most systems is high, your post also implies to a casual reader that the cost is fundamental. This is not true. As demonstrated in the benchmark, the hardware cost of systems calls/trapping is quite low. Even accounting for hardware workarounds (which were not even known about when the common consensus decided system calls were slow), excepting the case of hardware virtualization which has much more expensive mitigations, the fundamental cost is a fraction of the actual cost. The majority of the cost (~90+%) is actually due to software. In the system call case this is the implementation of the system call. In the contex…
View on Hacker News

scottlambon Hacker News • Mentions

On “A hybrid thread / fiber task scheduler written in C++ 11”

…is that most of the overhead of kernel threads is the scheduling and userspace has the ability to make a quick good choice. 3 Thus you can get most of the CPU performance of an async implementation but the relatively easy-to-read callback-free code of a threaded implementation. Anyway, people can disagree on what to call such a combination. 1 link to this video 2 the rseq stuff described in that talk has been upstreamed 4 but the switchto stuff still hasn't. 3 I'm not sure if the performance argument is as strong since the Meltdown/Spectre mitigations added to the performance cost of any syscall. 4 link…
View on Hacker News

nwliebon Hacker News • Mentions

On “A hybrid thread / fiber task scheduler written in C++ 11”

Could you describe what makes the Google Fibers so nice? I'm also really curious why they require modifications to the Linux kernel. My first guess would be stronger integration with the IO model at the syscall boundary (similar to io_uring). Edit: is this the talk your referring to? link to this video
View on Hacker News