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

ApplicationCores is always initiated with 8 #64

Closed
ShiruRen opened this issue Jun 11, 2018 · 4 comments
Closed

ApplicationCores is always initiated with 8 #64

ShiruRen opened this issue Jun 11, 2018 · 4 comments
Assignees

Comments

@ShiruRen
Copy link
Contributor

I am currently using gVisor with Docker. I found the number of processors in /proc/cpuinfo is always 8, which limits the the amount of CPUs that some applications can use (e.g., TensorFlow). When I step through the code I found that the ApplicationCores is always initiated with 8 when initiating the Kernel object [https://github.com/google/gvisor/blob/7049f4480dabac4b95a9117eafc47f4b2b3f24f5/runsc/boot/loader.go#L172]. I am wondering if it would be possible to set the value straight from host /proc/cpuinfo like the func initCPUFreq() does.

I am also wondering if there are any known solutions to limit the amount of resources (like CPUs and memory) that a container can use.

Docker version: 18.03.1-ce
The command run was docker run --runtime=runsc -it ubuntu /bin/bash

Thanks.

@prattmic
Copy link
Member

w.r.t. resource isolation, see #62 (runsc will eventually put itself inside of appropriate cgroups according to the spec).

@fvoznika
Copy link
Member

We need to get the number of processor from cgroups when we add support for it. But for now, we could use the number of processors on the machine.

@fvoznika fvoznika self-assigned this Jun 15, 2018
@fvoznika
Copy link
Member

Resolved by 4de9647

@ShiruRen
Copy link
Contributor Author

Many thanks, @fvoznika @prattmic . It works fine now.

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