From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Tejun Heo <tj@kernel.org>
Cc: David Rientjes <rientjes@google.com>,
Michal Hocko <mhocko@suse.cz>, Zhouping Liu <zliu@redhat.com>,
linux-mm@kvack.org, Li Zefan <lizefan@huawei.com>,
CAI Qian <caiqian@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: memcg: cat: memory.memsw.* : Operation not supported
Date: Thu, 28 Jun 2012 13:04:16 +0900 [thread overview]
Message-ID: <4FEBD7C0.7090906@jp.fujitsu.com> (raw)
In-Reply-To: <20120627202430.GS15811@google.com>
(2012/06/28 5:24), Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 27, 2012 at 01:21:27PM -0700, David Rientjes wrote:
>> Well it also has a prerequisite that memcg doesn't have: CONFIG_SWAP, so
>
> Right.
>
>> even if CONFIG_CGROUP_MEM_RES_CTLR_SWAP is folded into
>> CONFIG_CGROUP_MEM_RES_CTLR, then these should still depend on CONFIG_SWAP
>> since configuring them would imply there is some limit to be enforced.
>>
>> But to answer your question:
>>
>> text data bss dec hex filename
>> 25777 3644 4128 33549 830d memcontrol.o.swap_disabled
>> 27294 4476 4128 35898 8c3a memcontrol.o.swap_enabled
>
> I still wish it's folded into CONFIG_MEMCG and conditionalized just on
> CONFIG_SWAP tho.
>
In old days, memsw controller was not very stable. So, we devided the config.
And, it makes size of memory for swap-device double (adds 2bytes per swapent.)
That is the problem.
>> Is it really too painful to not create these files when
>> CONFIG_CGROUP_MEM_RES_CTLR_SWAP is disabled? If so, can we at least allow
>> them to be opened but return -EINVAL if memory.memsw.limit_in_bytes is
>> written?
>
> Not at all, that was the first version anyway, which (IIRC) KAME
> didn't like and suggested always creating those files. KAME, what do
> you think?
>
IIRC...at that time, we made decision, cgroup has no feature to
'create files dynamically'. Then, we made it in static, decision was done
at compile time and ignores "do_swap_account".
Now, IIUC, we have the feature. So, it's may be a time to create the file
with regard to "do_swap_account", making decision at boot time.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Tejun Heo <tj@kernel.org>
Cc: David Rientjes <rientjes@google.com>,
Michal Hocko <mhocko@suse.cz>, Zhouping Liu <zliu@redhat.com>,
linux-mm@kvack.org, Li Zefan <lizefan@huawei.com>,
CAI Qian <caiqian@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: memcg: cat: memory.memsw.* : Operation not supported
Date: Thu, 28 Jun 2012 13:04:16 +0900 [thread overview]
Message-ID: <4FEBD7C0.7090906@jp.fujitsu.com> (raw)
In-Reply-To: <20120627202430.GS15811@google.com>
(2012/06/28 5:24), Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 27, 2012 at 01:21:27PM -0700, David Rientjes wrote:
>> Well it also has a prerequisite that memcg doesn't have: CONFIG_SWAP, so
>
> Right.
>
>> even if CONFIG_CGROUP_MEM_RES_CTLR_SWAP is folded into
>> CONFIG_CGROUP_MEM_RES_CTLR, then these should still depend on CONFIG_SWAP
>> since configuring them would imply there is some limit to be enforced.
>>
>> But to answer your question:
>>
>> text data bss dec hex filename
>> 25777 3644 4128 33549 830d memcontrol.o.swap_disabled
>> 27294 4476 4128 35898 8c3a memcontrol.o.swap_enabled
>
> I still wish it's folded into CONFIG_MEMCG and conditionalized just on
> CONFIG_SWAP tho.
>
In old days, memsw controller was not very stable. So, we devided the config.
And, it makes size of memory for swap-device double (adds 2bytes per swapent.)
That is the problem.
>> Is it really too painful to not create these files when
>> CONFIG_CGROUP_MEM_RES_CTLR_SWAP is disabled? If so, can we at least allow
>> them to be opened but return -EINVAL if memory.memsw.limit_in_bytes is
>> written?
>
> Not at all, that was the first version anyway, which (IIRC) KAME
> didn't like and suggested always creating those files. KAME, what do
> you think?
>
IIRC...at that time, we made decision, cgroup has no feature to
'create files dynamically'. Then, we made it in static, decision was done
at compile time and ignores "do_swap_account".
Now, IIUC, we have the feature. So, it's may be a time to create the file
with regard to "do_swap_account", making decision at boot time.
Thanks,
-Kame
next prev parent reply other threads:[~2012-06-28 4:06 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2a1a74bf-fbb5-4a6e-b958-44fff8debff2@zmail13.collab.prod.int.phx2.redhat.com>
2012-06-27 3:49 ` memcg: cat: memory.memsw.* : Operation not supported Zhouping Liu
2012-06-27 3:49 ` Zhouping Liu
2012-06-27 15:48 ` Michal Hocko
2012-06-27 15:48 ` Michal Hocko
2012-06-27 20:04 ` David Rientjes
2012-06-27 20:04 ` David Rientjes
2012-06-27 20:09 ` Tejun Heo
2012-06-27 20:09 ` Tejun Heo
2012-06-27 20:21 ` David Rientjes
2012-06-27 20:21 ` David Rientjes
2012-06-27 20:24 ` Tejun Heo
2012-06-27 20:24 ` Tejun Heo
2012-06-27 20:26 ` David Rientjes
2012-06-27 20:26 ` David Rientjes
2012-06-28 4:04 ` Kamezawa Hiroyuki [this message]
2012-06-28 4:04 ` Kamezawa Hiroyuki
2012-06-28 18:31 ` Tejun Heo
2012-06-28 18:31 ` Tejun Heo
2012-06-30 3:45 ` Kamezawa Hiroyuki
2012-06-30 3:45 ` Kamezawa Hiroyuki
2013-01-21 8:39 ` Zhouping Liu
2013-01-21 8:39 ` Zhouping Liu
2013-01-21 10:56 ` Michal Hocko
2013-01-21 10:56 ` Michal Hocko
2013-01-21 11:12 ` Michal Hocko
2013-01-21 11:12 ` Michal Hocko
2013-01-21 13:27 ` Zhouping Liu
2013-01-21 13:27 ` Zhouping Liu
2013-01-21 13:46 ` Michal Hocko
2013-01-21 13:46 ` Michal Hocko
2012-06-29 7:16 ` Glauber Costa
2012-06-29 7:16 ` Glauber Costa
2012-06-28 12:36 ` Michal Hocko
2012-06-28 12:36 ` Michal Hocko
2012-06-28 18:29 ` Tejun Heo
2012-06-28 18:29 ` Tejun Heo
2012-06-29 0:11 ` Kamezawa Hiroyuki
2012-06-29 0:11 ` Kamezawa Hiroyuki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FEBD7C0.7090906@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=caiqian@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=mhocko@suse.cz \
--cc=rientjes@google.com \
--cc=tj@kernel.org \
--cc=zliu@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.