From: Glauber Costa <glommer@parallels.com>
To: Greg Thelen <gthelen@google.com>
Cc: <linux-kernel@vger.kernel.org>, <paul@paulmenage.org>,
<lizf@cn.fujitsu.com>, <kamezawa.hiroyu@jp.fujitsu.com>,
<ebiederm@xmission.com>, <davem@davemloft.net>,
<netdev@vger.kernel.org>, <linux-mm@kvack.org>,
<kirill@shutemov.name>, <avagin@parallels.com>,
<devel@openvz.org>
Subject: Re: [PATCH v6 1/8] Basic kernel memory functionality for the Memory Controller
Date: Thu, 13 Oct 2011 12:19:37 +0400 [thread overview]
Message-ID: <4E969F19.4010802@parallels.com> (raw)
In-Reply-To: <CAHH2K0awiPZZ9EJLyZy_p_ehf0-waQ-vGUAhAZEpdCMnYqKidA@mail.gmail.com>
On 10/13/2011 11:18 AM, Greg Thelen wrote:
> On Mon, Oct 10, 2011 at 3:24 AM, Glauber Costa<glommer@parallels.com> wrote:
>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>> index 06eb6d9..bf00cd2 100644
>> --- a/Documentation/cgroups/memory.txt
>> +++ b/Documentation/cgroups/memory.txt
> ...
>> @@ -255,6 +262,31 @@ When oom event notifier is registered, event will be delivered.
>> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
>> zone->lru_lock, it has no lock of its own.
>>
>> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
>> +
>> + With the Kernel memory extension, the Memory Controller is able to limit
>
> Extra leading space before 'With'.
>
>> +the amount of kernel memory used by the system. Kernel memory is fundamentally
>> +different than user memory, since it can't be swapped out, which makes it
>> +possible to DoS the system by consuming too much of this precious resource.
>> +Kernel memory limits are not imposed for the root cgroup.
>> +
>> +Memory limits as specified by the standard Memory Controller may or may not
>> +take kernel memory into consideration. This is achieved through the file
>> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
>
> s/Value/value/
>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 3508777..d25c5cb 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
> ...
>> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
>> + u64 val)
>> +{
>> + cgroup_lock();
>> + mem_cgroup_from_cont(cont)->kmem_independent_accounting = !!val;
>> + cgroup_unlock();
>
> I do not think cgroup_lock,unlock are needed here. The cont and
> associated cgroup should be guaranteed by the caller to be valid.
> Does this lock provide some other synchronization?
Yeah, I think I was being overcautious.
With the following comments addressed, can I add your Reviewed-by to
this one ?
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: Greg Thelen <gthelen@google.com>
Cc: linux-kernel@vger.kernel.org, paul@paulmenage.org,
lizf@cn.fujitsu.com, kamezawa.hiroyu@jp.fujitsu.com,
ebiederm@xmission.com, davem@davemloft.net,
netdev@vger.kernel.org, linux-mm@kvack.org, kirill@shutemov.name,
avagin@parallels.com, devel@openvz.org
Subject: Re: [PATCH v6 1/8] Basic kernel memory functionality for the Memory Controller
Date: Thu, 13 Oct 2011 12:19:37 +0400 [thread overview]
Message-ID: <4E969F19.4010802@parallels.com> (raw)
In-Reply-To: <CAHH2K0awiPZZ9EJLyZy_p_ehf0-waQ-vGUAhAZEpdCMnYqKidA@mail.gmail.com>
On 10/13/2011 11:18 AM, Greg Thelen wrote:
> On Mon, Oct 10, 2011 at 3:24 AM, Glauber Costa<glommer@parallels.com> wrote:
>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>> index 06eb6d9..bf00cd2 100644
>> --- a/Documentation/cgroups/memory.txt
>> +++ b/Documentation/cgroups/memory.txt
> ...
>> @@ -255,6 +262,31 @@ When oom event notifier is registered, event will be delivered.
>> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
>> zone->lru_lock, it has no lock of its own.
>>
>> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
>> +
>> + With the Kernel memory extension, the Memory Controller is able to limit
>
> Extra leading space before 'With'.
>
>> +the amount of kernel memory used by the system. Kernel memory is fundamentally
>> +different than user memory, since it can't be swapped out, which makes it
>> +possible to DoS the system by consuming too much of this precious resource.
>> +Kernel memory limits are not imposed for the root cgroup.
>> +
>> +Memory limits as specified by the standard Memory Controller may or may not
>> +take kernel memory into consideration. This is achieved through the file
>> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
>
> s/Value/value/
>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 3508777..d25c5cb 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
> ...
>> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
>> + u64 val)
>> +{
>> + cgroup_lock();
>> + mem_cgroup_from_cont(cont)->kmem_independent_accounting = !!val;
>> + cgroup_unlock();
>
> I do not think cgroup_lock,unlock are needed here. The cont and
> associated cgroup should be guaranteed by the caller to be valid.
> Does this lock provide some other synchronization?
Yeah, I think I was being overcautious.
With the following comments addressed, can I add your Reviewed-by to
this one ?
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: Greg Thelen <gthelen@google.com>
Cc: <linux-kernel@vger.kernel.org>, <paul@paulmenage.org>,
<lizf@cn.fujitsu.com>, <kamezawa.hiroyu@jp.fujitsu.com>,
<ebiederm@xmission.com>, <davem@davemloft.net>,
<netdev@vger.kernel.org>, <linux-mm@kvack.org>,
<kirill@shutemov.name>, <avagin@parallels.com>,
<devel@openvz.org>
Subject: Re: [PATCH v6 1/8] Basic kernel memory functionality for the Memory Controller
Date: Thu, 13 Oct 2011 12:19:37 +0400 [thread overview]
Message-ID: <4E969F19.4010802@parallels.com> (raw)
In-Reply-To: <CAHH2K0awiPZZ9EJLyZy_p_ehf0-waQ-vGUAhAZEpdCMnYqKidA@mail.gmail.com>
On 10/13/2011 11:18 AM, Greg Thelen wrote:
> On Mon, Oct 10, 2011 at 3:24 AM, Glauber Costa<glommer@parallels.com> wrote:
>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>> index 06eb6d9..bf00cd2 100644
>> --- a/Documentation/cgroups/memory.txt
>> +++ b/Documentation/cgroups/memory.txt
> ...
>> @@ -255,6 +262,31 @@ When oom event notifier is registered, event will be delivered.
>> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
>> zone->lru_lock, it has no lock of its own.
>>
>> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
>> +
>> + With the Kernel memory extension, the Memory Controller is able to limit
>
> Extra leading space before 'With'.
>
>> +the amount of kernel memory used by the system. Kernel memory is fundamentally
>> +different than user memory, since it can't be swapped out, which makes it
>> +possible to DoS the system by consuming too much of this precious resource.
>> +Kernel memory limits are not imposed for the root cgroup.
>> +
>> +Memory limits as specified by the standard Memory Controller may or may not
>> +take kernel memory into consideration. This is achieved through the file
>> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
>
> s/Value/value/
>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 3508777..d25c5cb 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
> ...
>> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
>> + u64 val)
>> +{
>> + cgroup_lock();
>> + mem_cgroup_from_cont(cont)->kmem_independent_accounting = !!val;
>> + cgroup_unlock();
>
> I do not think cgroup_lock,unlock are needed here. The cont and
> associated cgroup should be guaranteed by the caller to be valid.
> Does this lock provide some other synchronization?
Yeah, I think I was being overcautious.
With the following comments addressed, can I add your Reviewed-by to
this one ?
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-10-13 8:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-10 10:24 [PATCH v6 0/8] per-cgroup tcp memory pressure handling Glauber Costa
2011-10-10 10:24 ` Glauber Costa
2011-10-10 10:24 ` [PATCH v6 1/8] Basic kernel memory functionality for the Memory Controller Glauber Costa
2011-10-10 10:24 ` Glauber Costa
2011-10-13 5:44 ` KAMEZAWA Hiroyuki
2011-10-13 5:44 ` KAMEZAWA Hiroyuki
2011-10-13 7:18 ` Greg Thelen
2011-10-13 7:18 ` Greg Thelen
2011-10-13 8:19 ` Glauber Costa [this message]
2011-10-13 8:19 ` Glauber Costa
2011-10-13 8:19 ` Glauber Costa
2011-10-10 10:24 ` [PATCH v6 2/8] socket: initial cgroup code Glauber Costa
2011-10-10 10:24 ` Glauber Costa
2011-10-10 10:24 ` [PATCH v6 3/8] foundations of per-cgroup memory pressure controlling Glauber Costa
2011-10-10 10:24 ` Glauber Costa
2011-10-13 5:53 ` KAMEZAWA Hiroyuki
2011-10-13 5:53 ` KAMEZAWA Hiroyuki
2011-10-13 8:25 ` Glauber Costa
2011-10-13 8:25 ` Glauber Costa
2011-10-13 8:25 ` Glauber Costa
2011-10-10 10:24 ` [PATCH v6 4/8] per-cgroup tcp buffers control Glauber Costa
2011-10-10 10:24 ` Glauber Costa
2011-10-13 5:56 ` KAMEZAWA Hiroyuki
2011-10-13 5:56 ` KAMEZAWA Hiroyuki
2011-10-10 10:24 ` [PATCH v6 5/8] per-netns ipv4 sysctl_tcp_mem Glauber Costa
2011-10-10 10:24 ` Glauber Costa
2011-10-10 10:24 ` [PATCH v6 6/8] tcp buffer limitation: per-cgroup limit Glauber Costa
2011-10-10 10:24 ` Glauber Costa
2011-10-13 5:58 ` KAMEZAWA Hiroyuki
2011-10-13 5:58 ` KAMEZAWA Hiroyuki
2011-10-10 10:24 ` [PATCH v6 7/8] Display current tcp memory allocation in kmem cgroup Glauber Costa
2011-10-10 10:24 ` Glauber Costa
2011-10-13 5:59 ` KAMEZAWA Hiroyuki
2011-10-13 5:59 ` KAMEZAWA Hiroyuki
2011-10-10 10:24 ` [PATCH v6 8/8] Disable task moving when using kernel memory accounting Glauber Costa
2011-10-10 10:24 ` Glauber Costa
2011-10-13 6:00 ` KAMEZAWA Hiroyuki
2011-10-13 6:00 ` 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=4E969F19.4010802@parallels.com \
--to=glommer@parallels.com \
--cc=avagin@parallels.com \
--cc=davem@davemloft.net \
--cc=devel@openvz.org \
--cc=ebiederm@xmission.com \
--cc=gthelen@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@cn.fujitsu.com \
--cc=netdev@vger.kernel.org \
--cc=paul@paulmenage.org \
/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.