alt.hn

5/18/2025 at 5:03:55 PM

Understanding the Go Scheduler

 https://nghiant3223.github.io/2025/04/15/go-scheduler.html

by gnabgib

5/21/2025 at 8:11:14 PM

Make sure you set GOMAXPROCS when the runtime is cgroup limited.

I once profiled a slow go program running on a node with 168 cores, but cpu.max was 2 cores for the cgroup. The runtime defaults to set GOMAXPROCS to the number of visible cores which was 168 in this case. Over half the runtime was the scheduler bouncing goroutines between 168 processes despite cpu.max being 2 CPU.

The JRE is smart enough to figure out if it is running in a resource limited cgroup and make sane decisions based upon that, but golang has no such thing.

by __turbobrew__

5/21/2025 at 8:17:05 PM

Relevant proposal to make GOMAXPROCS cgroup-aware: https://github.com/golang/go/issues/73193

by xyzzy_plugh

5/22/2025 at 5:42:41 AM

Looks like it was just merged btw.

by robinhoodexe

5/21/2025 at 8:42:51 PM

This should be automatic these days (for the basic scenarios).

https://github.com/golang/go/blob/a1a151496503cafa5e4c672e0e...

by yencabulator

5/21/2025 at 10:31:42 PM

This is probably going to save quadrillions of CPU cycles by making an untold number of deployed Go applications a bit more CPU efficient. Since Go is the "lingua franca" of containers, many ops people assume the Go runtime is container-aware - it's not (well not in any released version, yet).

If they'd now also make the GC respect memory cgroup limits (i.e. automatic GOMEMLIMIT), we'd probably be freeing up a couple petabytes of memory across the globe.

Java has been doing these things for a while, even OpenJDK 8 has had those patches since probably before covid.

by formerly_proven

5/22/2025 at 8:56:40 AM

As long as I admit respecting cgroup's setting is a good thing, I am not sure it's really quadrillions.

Or is it? Need calculations

by kunley

5/22/2025 at 3:26:53 PM

I would've expected it to be either way too much or way too little, but after doing the math it could be sorta in the right ballpark, at least cosmically speaking.

Let's go with three quadrillion (which is apparently 10^15), let's assume a server CPU does 3 GHz (10^9), that's 10^6, a day is about 100k seconds, so ~ten days. But of course we're only saving cycles. I've seen throughput increase by about 50% when setting GOMAXPROCS on bigger machines, but in most of those cases we're looking at containers with fractional cores. On the other hand, there are many containers. So...

by formerly_proven

5/23/2025 at 9:18:34 AM

Nice reasoning, thanks.

Hey, but what did you have in mind with regard to bigger machines? I think we're talking here about lowering GOMAXPROCS to have in effect less context switching of the OS threads. While it can bring some good result, a gut feeling is that it'd be hardly 50% faster overall, is your scenario the same then?

by kunley

5/21/2025 at 11:24:01 PM

GOMEMLIMIT is not as easy, you may have other processes in the same container/cgroup also using memory.

by mappu

5/21/2025 at 8:48:17 PM

uh isn't that change 3 hours old?

by jasonthorsness

5/21/2025 at 8:59:37 PM

Oh heh yes it is. I just remembered the original discussion from 2019 (https://github.com/golang/go/issues/33803) and grepped the source tree for cgroup to see if that got done or not, but didn't check when it got done.

As said in 2019, import https://github.com/uber-go/automaxprocs to get the functionality ASAP.

by yencabulator

5/21/2025 at 10:50:52 PM

I honestly can’t count on my fingers and toes how many times something very precisely relevant to me was brought up or sorted out hours-to-days before I looked it up. And more often than once, by people I personally knew!

Always a weird feeling, it’s a small world

by williamdclt

5/21/2025 at 9:16:02 PM

super-weird coincidence but welcome, I have been waiting for this for a long time!

by jasonthorsness

5/22/2025 at 2:17:15 AM

Trying to see if Rust and Tokio have the same problem. I don't know enough about cgroups to be sure. Tokio at this line [1] ends up delegating to `std::thread::available_parallelism` [2] which says

> It may overcount the amount of parallelism available when limited by a process-wide affinity mask or cgroup quotas and sched_getaffinity() or cgroup fs can’t be queried, e.g. due to sandboxing.

[1] https://docs.rs/tokio/1.45.0/src/tokio/loom/std/mod.rs.html#...

[2] https://doc.rust-lang.org/stable/std/thread/fn.available_par...

by 01HNNWZ0MV43FF

5/22/2025 at 9:34:53 AM

Probably not?

The fundamental issue comes down to background GC and CPU quotas in cgroups.

If your number of worker threads is too high, GC will eat up all the quota.

by nvarsj

5/21/2025 at 8:02:43 PM

It's always a sign of good design when something as complex as the scheduler described "just works" with the simple abstraction of the goroutine. What a great article.

"1/61 of the time, check the global run queue." Stuff like this is a little odd; I would have thought this would be a variable dependent on the number of physical cores.

by jasonthorsness

5/22/2025 at 2:18:51 AM

That's so funny. I just saw `61` in the Tokio code with a comment "copied this from Go"

by 01HNNWZ0MV43FF

5/21/2025 at 9:00:27 PM

Fantastic writeup! Visualizations are great, the writeup is thorough but readable.

by kortex

5/22/2025 at 2:56:18 AM

Your write-up is so detailed that I even feel like I could implement a complete golang scheduler myself

by weiwenhao

5/22/2025 at 4:21:05 PM

I'd be interested in seeing a comparison of this and the BEAM/Erlang/Elixir scheduler by someone paying attention to the details.

by davidw

5/21/2025 at 6:16:31 PM

I heard that the scheduler is a huge obstacle to many potential optimizations, is that true?

by 90s_dev

5/21/2025 at 7:42:33 PM

In some ways, yes. If you want to optimize at that level you ought to use another language.

I'm not a low level optimization guy, but I've had occasions where I wanted control over which threads my goroutines are running on or prioritizing important goroutines. It's a trade off for making things less complex, which is standard for Go.

I suppose there's always hope that the Go developers can change things.

by NAHWheatCracker

5/21/2025 at 8:06:35 PM

You can kinda work around this though. runtime package has a LockOSThread that pins a goroutine to its current thread and prevents others from using it.

If you model it in a way where you have one goroutine per os thread that receives and does work, it gets you close. But in many cases that means rearching the entire code base, as it's not a style I typically reach for.

by silisili

5/22/2025 at 12:46:55 AM

That sounds a lot like just using another language.

by naikrovek

5/23/2025 at 2:14:30 AM

If you need it here or there, no. I've got a use case where I need a single locked thread for a particular syscall's functionality. It's not like it leaks out into the rest of the program and everything else has to change to accomodate it.

If you need it pervasively, Go may not be the correct choice. Then again, the list of languages that is not a correct choice in that case is quite long. That's a minority case. An important one, but a minority one.

by jerf

5/22/2025 at 1:25:29 AM

It's really not that bad. If you have a codebase in Go you can speed up, it's fine.

That said, if you're greenfielding and see this as a limitation to begin with, picking another language is probably the right way.

by silisili