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

BLKIO weight device fails to set in /sys with 3.18.8 kernel #140

Closed
rajasec opened this issue Jul 19, 2015 · 8 comments
Closed

BLKIO weight device fails to set in /sys with 3.18.8 kernel #140

rajasec opened this issue Jul 19, 2015 · 8 comments

Comments

@rajasec
Copy link
Contributor

rajasec commented Jul 19, 2015

I modified the config.json file under resources
"blkioWeightDevice": "500"

After starting the container
it fails to start the container, Error thrown out
Container start failed: [8] System error: write /sys/fs/cgroup/blkio/user/1000.user/c2.session/runc/blkio.weight_device: invalid argument

cgroups/fs/blkio_test.go
Even the blkio_test.go is setting the weight device value in /tmp folder as destination which is the reason for passing the tests. If the destination is /sys tests would have been failed.

Kernel : 3.18.8
Machine : Ubuntu

@rajasec
Copy link
Contributor Author

rajasec commented Jul 19, 2015

For testing purpose, I've added template_test.go for adding block device support, this time it fails..
System error: write /sys/fs/cgroup/blkio/integration/test/blkio.weight_device: invalid argument
Even the tests failed in integration directory
Overall felt that, blkio.weight_device is not allowing to write in /sys

@rajasec
Copy link
Contributor Author

rajasec commented Jul 19, 2015

Ubuntu comes with deadline I/O scheduler as default, due to which blkio weight device is not writing to /sys.
The moment I've changed to cfq scheduler, I'm able to set the values in blkio.weight_device.
Even I've tested with noop scheduler, same failure.
Looks like, blkio weightage supports only in CFQ I/O scheduler.
Even though I modified to CFQ, few of the things blkio.time is not allowing to write

@rajasec
Copy link
Contributor Author

rajasec commented Jul 19, 2015

As per Kernel code, cfq-iosched.c, weight device works for CFQ..
{
.name = "weight_device",
.flags = CFTYPE_NOT_ON_ROOT,
.seq_show = cfqg_print_weight_device,
.write = cfqg_set_weight_device,
},
@crosbymichael @mrunalp
Is there way to solve for deadline schedulers which comes with default value.

@mrunalp
Copy link
Contributor

mrunalp commented Jul 20, 2015

@rajasec From the kernel documentation here https://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt

Currently two IO control policies are implemented. First one is proportional
weight time based division of disk policy. It is implemented in CFQ. Hence
this policy takes effect only on leaf nodes when CFQ is being used.

@hqhq
Copy link
Contributor

hqhq commented Jul 21, 2015

@rajasec blkio weight can't be used on deadline scheduler, and the solution should be on kernel side. All Docker can do is give a more specific message, current one is not that friendly.
For not allowing to write to blkio.time, that's because it can't be written, it only for showing blkio cgroup data, you can ll /sys/fs/cgroup/blkio and find out which files are allowed to be written.

@rajasec
Copy link
Contributor Author

rajasec commented Jul 21, 2015

Thanks @hqhq @mrunalp for the confirmation
For database operations which ran on the separate disks with deadline scheduler, now we are forced to switched to cfq. BLKIO for database operations can not be utilized.

@rajasec
Copy link
Contributor Author

rajasec commented Jul 31, 2015

Closing this issue as it is current design from Kernel to support cfq only for blkio subsystem of cgroups

@jia-zhengwei
Copy link

jia-zhengwei commented Dec 26, 2018

@hqhq , hello, 请问cgroup没有挂载到clkio.weight等(如下图)应该如何做才能挂载。
dockerd log:
image
cgroup folder/file:
image

and also, why the group/user is 15 not root?

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

4 participants