← Back to team overview

kernel-packages team mailing list archive

Re: [Bug 1568592] Re: bug of "memory.kmem.limit_in_bytes" and "memory.kmem.usage_in_bytes"


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

> 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

> 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.
        if (cgroup_is_populated(memcg->css.cgroup) ||
            (memcg->use_hierarchy && memcg_has_children(memcg)))
                err = -EBUSY;
        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

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

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  bug of "memory.kmem.limit_in_bytes" and "memory.kmem.usage_in_bytes"

Status in linux package in Ubuntu:

Bug description:
  In ubuntuxenial with linux kernel 4.4,

  "memory.kmem.limit_in_bytes" cannot be written,

  and the value of "memory.kmem.usage_in_bytes" is always 0.

  This issue doesn't happen in ubuntu wily (kernel = 4.2)

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-generic
  ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
  Uname: Linux 4.4.0-18-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  AlsaVersion: Advanced Linux Sound Architecture Driver Version k4.4.0-18-generic.
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
   /dev/snd/controlC0:  ghostplant   2724 F.... pulseaudio
   /dev/snd/controlC1:  ghostplant   2724 F.... pulseaudio
  CurrentDesktop: GNOME-Flashback:Unity
  Date: Mon Apr 11 03:24:49 2016
   Error: command ['journalctl', '-b', '--priority=warning', '--lines=1000'] failed with exit code 1: Hint: You are currently not seeing messages from other users and the system.
         Users in the 'systemd-journal' group can see all messages. Pass -q to
         turn off this notice.
   No journal files were opened due to insufficient permissions.
  MachineType: Micro-Star International Co., Ltd. GE60 2PG

  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-18-generic root=UUID=9b9acac2-b16b-4328-abc9-407fe4ce4e4d ro quiet swapaccount=1
   linux-restricted-modules-4.4.0-18-generic N/A
   linux-backports-modules-4.4.0-18-generic  N/A
   linux-firmware                            1.157
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)

  dmi.bios.date: 12/01/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: E16GFIMS.626
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: MS-16GF
  dmi.board.vendor: Micro-Star International Co., Ltd.
  dmi.board.version: REV:0.B
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrE16GFIMS.626:bd12/01/2014:svnMicro-StarInternationalCo.,Ltd.:pnGE602PG:pvrREV1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMS-16GF:rvrREV0.B:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.name: GE60 2PG
  dmi.product.version: REV:1.0
  dmi.sys.vendor: Micro-Star International Co., Ltd.

To manage notifications about this bug go to: