Issue #21797 has been updated by osyoyu (Daisuke Aritomo). Thank you for the summary! I'll open a separate ticket for auto-adjusting `RUBY_MAX_CPU`. Come to think of it, `RUBY_MAX_CPU` may have different requirements from `Etc.nprocessors` (defaulting to max # of processors may be suboptimal), so I think these can have separate implementations. In that case, `Etc.nprocessors` can have its own Ruby impl in ext/etc, and `RUBY_MAX_CPU` could have another in the core (presumably in C), even though they might end up being similar. ---------------------------------------- Feature #21797: Make Etc.nprocessors cgroup-aware on Linux https://bugs.ruby-lang.org/issues/21797#change-115897 * Author: moznion (Taiki Kawakami) * Status: Open ---------------------------------------- Currently, `Etc.nprocessors` ignores cgroup CPU quotas. This causes issues in containers where CPU limits differ from the host CPU count. I have written a gem for this purpose (https://github.com/moznion/maxprocs-ruby), but it would be preferable if the Ruby core implementation respected cgroup configuration. Additionally, concurrent-ruby provides similar functionality, but if the language itself offered this capability, language users would not need to implement it individually. And some parts of the Ruby language handle the number of processors using hard-coded values (e.g., https://github.com/ruby/ruby/blob/8efaf5e6b6a25e0d237f3d71b75865661ae98268/t...), so this could also be useful for Ruby language development. Extending `Etc.nprocessors` to respect cgroups is one option, but that would be a breaking change, so adding a new API (e.g., `Etc.cpu_quota` or something?) might be a better approach. ## Prior Art - Go 1.25: runtime GOMAXPROCS (Issue [#73193](https://github.com/golang/go/issues/73193)) - [uber-go/automaxprocs](https://github.com/uber-go/automaxprocs) - [concurrent-ruby](https://github.com/ruby-concurrency/concurrent-ruby): https://github.com/ruby-concurrency/concurrent-ruby/blob/129cf004294af68ac53... -- https://bugs.ruby-lang.org/