Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support dynamic sched::CpuSet size for machines with >64 cores #2589

Open
gsnoff opened this issue Jan 29, 2025 · 0 comments
Open

Support dynamic sched::CpuSet size for machines with >64 cores #2589

gsnoff opened this issue Jan 29, 2025 · 0 comments

Comments

@gsnoff
Copy link

gsnoff commented Jan 29, 2025

Currently the CpuSet struct consists of a single cpu_set_t (or cpuset_t on *BSD), and sched_*etaffinity syscalls are called with constant cpusetsize parameter, always being mem::size_of::<CpuSet>() (=64 on all targets, at least those I care about) regardless of what the value of sysconf(_SC_NPROCESSORS_CONF) would be.

What I would like to see is some future-proof design, that would support for a runtime-sized allocation of cpu_set_t slice, similarly to what C macros such as CPU_ALLOC() facilitate.

For example, I can see this being abstracted behind CpuSet being an enum internally, that either has some default sized stack value, or dynamically sized slice on heap, and the affinity calls picking the logic depending on the variant. Or there could be two types like CpuSet and CpuSetDyn implementing the same (unsafe?) trait, providing cpusetsize and a pointer to the first cpuset_t, making the affinity fns generic over this trait.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant