On Mon, Apr 11, 2016 at 03:44:37PM -0000, Cui Wei wrote:
> Hi, after full upgrade, "memory.kmem.limit_in_bytes" and
> "memory.kmem.usage_in_bytes" works not after executing docker with
> "--kernel-memory" argument.
So your problem then is that you want to start a container without the
--kernel-memory argument the change it later by writing to
memory.kmem.usage_in_bytes directly? That wasn't clear from your earlier
comments.
> But if you run a command like "docker run -it --rm ubuntu bash" without
> --kernel-memory argument,
>
> are you able to get the correct value of "cat
> /sys/fs/cgroup/memory/docker/e4ed03caa58b3035ea028de5c17015012aea476f166d004440eccb266f208c4a/memory.kmem.usage_in_bytes"
> ?
Well, I get 9223372036854771712 or 0x7FFFFFFFFFFFF000. The default value
in pages is (LONG_MAX / PAGE_SIZE), or 0x7FFFFFFFFFFFF. Muliply that by
PAGE_SIZE (i.e. 4096) and you get the number I read, so yes, this seems
correct.
> Also, "echo 1G >
> /sys/fs/cgroup/memory/docker/e4ed03caa58b3035ea028de5c17015012aea476f166d004440eccb266f208c4a/memory.kmem.usage_in_bytes"
> will also be denied.
I'm pretty sure that what you're hitting here is this code in
memcg_activate_kmem() from the kernel:
/*
* For simplicity, we won't allow this to be disabled. It also can't
* be changed if the cgroup has children already, or if tasks had
* already joined.
*
* If tasks join before we set the limit, a person looking at
* kmem.usage_in_bytes will have no way to determine when it took
* place, which makes the value quite meaningless.
*
* After it first became limited, changes in the value of the limit are
* of course permitted.
*/
mutex_lock(&memcg_create_mutex);
if (cgroup_is_populated(memcg->css.cgroup) ||
(memcg->use_hierarchy && memcg_has_children(memcg)))
err = -EBUSY;
mutex_unlock(&memcg_create_mutex);
if (err)
goto out;
So the rules seem to be:
1. If the limit is set before any tasks join the cgroup, allow the
limit to be changed, even after tasks are added.
2. If tasks join the cgroup before the limit is changed it can never be
changed.
So, in the case where you pass --kernel-memory docker must set up the
limit before adding any tasks, therefore it is allowed and future
updates are also allowed. Without --kernel-memory it seems docker does
not set anything up in the cgroup before adding tasks so any updates to
the limits are not allowed.
All of this seems to be intentional and unchanged since kernel version
4.2. So if it works in wily then I have to wonder whether it's actually
caused by a change in docker and not a change in the kernel. What
happens if you install the wily 4.2 kernel in xenial and try the same
thing?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1568592
Title:
bug of "memory.kmem.limit_in_bytes" and "memory.kmem.usage_in_bytes"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1568592/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
