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

num_cpus::get()=0 on mipsel-unknown-linux-gnu #69

Open
kpp opened this issue Aug 8, 2018 · 10 comments
Open

num_cpus::get()=0 on mipsel-unknown-linux-gnu #69

kpp opened this issue Aug 8, 2018 · 10 comments

Comments

@kpp
Copy link

kpp commented Aug 8, 2018

See tokio-rs/tokio#400

@kpp
Copy link
Author

kpp commented May 7, 2019

ping

@seanmonstar
Copy link
Owner

I know nothing about mipsel.

PRs welcome.

@lnicola
Copy link

lnicola commented May 7, 2019

The seems to be missing a failsafe check for Linux in order not to return less than 1.

@seanmonstar
Copy link
Owner

Looks like there is a check, but not in the sched affinity branch.

@lnicola
Copy link

lnicola commented May 8, 2019

See #68.

@seanmonstar
Copy link
Owner

I think there's still a behavior question that needs answering for #68: should it fallback to just the count? Or should an affinity count of 0 mean "you aren't assigned any CPUs, so here, have just 1"?

@lnicola
Copy link

lnicola commented May 8, 2019

Does an affinity mask of 0 mean that the process is not running?

@lnicola
Copy link

lnicola commented May 8, 2019

On my system, sched_setaffinity with a mask of 0 returns EINVAL, which makes sense. So if the sched_getaffinity returns 0, then the affinity mask is broken on that system and the process shouldn't be running anyway. So we get no useful information, and we should handle that case as if sched_getaffinity returned an error.

I don't think returning 1 in this case is useful. We should fall back to sysconf.

Hmm, I actually have a mips (not mipsel though) device, but I don't know how to link with the C library there (uClibc?).

@seanmonstar
Copy link
Owner

I've been trying to research what others do in this case:

  • In OpenJDK, if sched_getaffinity(args) == 0, it has an assert(count > 0) and just returns it afterwards. So, seems like it would crash there?
  • In Golang, if the affinity mask has 0 set, it explicitly returns 1.

@lnicola
Copy link

lnicola commented May 8, 2019

If that's the C assert (the #include is missing), it crashes in "debug" builds and has no effect in release (NDEBUG) ones.

I don't really expect a lot of software to handle this case. Maybe the issue is a different one?

Also, this sounds fun:

The CPU affinity system calls were introduced in Linux kernel 2.5.8. The system call wrappers were introduced in glibc 2.3. Initially, the glibc interfaces included a cpusetsize argument, typed as
unsigned int. In glibc 2.3.3, the cpusetsize argument was removed, but was then restored in glibc 2.3.4, with type size_t.

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

3 participants