Issue #21797 has been updated by moznion (Taiki Kawakami). Thank you for your comments. Let me summarize the discussion. ### 1. Introducing a new API under `Etc` Introducing a method such as `Etc.cpu_quota`, which returns `Float | nil`, seems reasonable. ### 2. Changing the behavior of `Etc.nprocessors` Changing the behavior of `Etc.nprocessors` to respect cgroup-based values and fall back to the original logic when cgroups are unavailable. This would be a breaking change, but it would likely be beneficial for most use cases, and the negative impact should be minimal. ### 3. Injecting the number of actually available CPUs into `RUBY_MAX_CPU` This would be useful, but it should be handled as a separate ticket after this one is resolved. ### 4. Implementation approach Which is preferred: pure Ruby as a part of `ruby/etc` or C? --- What do you think? ---------------------------------------- Feature #21797: Make Etc.nprocessors cgroup-aware on Linux https://bugs.ruby-lang.org/issues/21797#change-115844 * 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/