Re: memcg: cat: memory.memsw.* : Operation not supported

From: David Rientjes
Date: Wed Jun 27 2012 - 16:04:48 EST


On Wed, 27 Jun 2012, Michal Hocko wrote:

> > # mount -t cgroup -o memory xxx /cgroup/
> > # ll /cgroup/memory.memsw.*
> > -rw-r--r--. 1 root root 0 Jun 26 23:17 /cgroup/memory.memsw.failcnt
> > -rw-r--r--. 1 root root 0 Jun 26 23:17 /cgroup/memory.memsw.limit_in_bytes
> > -rw-r--r--. 1 root root 0 Jun 26 23:17 /cgroup/memory.memsw.max_usage_in_bytes
> > -r--r--r--. 1 root root 0 Jun 26 23:17 /cgroup/memory.memsw.usage_in_bytes
> > # cat /cgroup/memory.memsw.*
> > cat: /cgroup/memory.memsw.failcnt: Operation not supported
> > cat: /cgroup/memory.memsw.limit_in_bytes: Operation not supported
> > cat: /cgroup/memory.memsw.max_usage_in_bytes: Operation not supported
> > cat: /cgroup/memory.memsw.usage_in_bytes: Operation not supported
> >
> > I'm confusing why it can't read memory.memsw.* files.
>
> Those files are exported if CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y even
> if the feature is turned off when any attempt to open the file returns
> EOPNOTSUPP which is exactly what you are seeing.
> This is a deliberate decision see: b6d9270d (memcg: always create memsw
> files if CONFIG_CGROUP_MEM_RES_CTLR_SWAP).
>

You mean af36f906c0f4?

> Does this help to explain your problem? Do you actually see any problem
> with this behavior?
>

I think it's a crappy solution and one that is undocumented in
Documentation/cgroups/memory.txt. If you can only enable swap accounting
at boot either via .config or the command line then these files should
never be added for CONFIG_CGROUP_MEM_RES_CTLR_SWAP=n or when
do_swap_account is 0. It's much easier to test if the feature is enabled
by checking for the presence of these files at the memcg mount point
rather than doing an open(2) and checking for -EOPNOTSUPP, which isn't
even a listed error code. I don't care how much cleaner it makes the
internal memcg code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/