All of lore.kernel.org
 help / color / mirror / Atom feed
From: Glauber Costa <glommer@parallels.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <linux-kernel@vger.kernel.org>, <paul@paulmenage.org>,
	<lizf@cn.fujitsu.com>, <ebiederm@xmission.com>,
	<davem@davemloft.net>, <gthelen@google.com>,
	<netdev@vger.kernel.org>, <linux-mm@kvack.org>,
	<kirill@shutemov.name>, <avagin@parallels.com>
Subject: Re: [PATCH v4 3/8] foundations of per-cgroup memory pressure controlling.
Date: Tue, 4 Oct 2011 11:13:50 +0400	[thread overview]
Message-ID: <4E8AB22E.2080007@parallels.com> (raw)
In-Reply-To: <20111004095715.479da44d.kamezawa.hiroyu@jp.fujitsu.com>

On 10/04/2011 04:57 AM, KAMEZAWA Hiroyuki wrote:
> On Mon,  3 Oct 2011 14:18:38 +0400
> Glauber Costa<glommer@parallels.com>  wrote:
>
>> This patch converts struct sock fields memory_pressure,
>> memory_allocated, sockets_allocated, and sysctl_mem (now prot_mem)
>> to function pointers, receiving a struct mem_cgroup parameter.
>>
>> enter_memory_pressure is kept the same, since all its callers
>> have socket a context, and the kmem_cgroup can be derived from
>> the socket itself.
>>
>> To keep things working, the patch convert all users of those fields
>> to use acessor functions.
>>
>> In my benchmarks I didn't see a significant performance difference
>> with this patch applied compared to a baseline (around 1 % diff, thus
>> inside error margin).
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: David S. Miller<davem@davemloft.net>
>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@jp.fujitsu.com>
>> CC: Eric W. Biederman<ebiederm@xmission.com>
>
> A nitpick.
>
>
>>   #ifdef CONFIG_INET
>>   struct sock;
>> +struct proto;
>>   #ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>   void sock_update_memcg(struct sock *sk);
>>   void sock_release_memcg(struct sock *sk);
>> -
>> +void memcg_sock_mem_alloc(struct mem_cgroup *mem, struct proto *prot,
>> +			  int amt, int *parent_failure);
>> +void memcg_sock_mem_free(struct mem_cgroup *mem, struct proto *prot, int amt);
>> +void memcg_sockets_allocated_dec(struct mem_cgroup *mem, struct proto *prot);
>> +void memcg_sockets_allocated_inc(struct mem_cgroup *mem, struct proto *prot);
>>   #else
>> +/* memcontrol includes sockets.h, that includes memcontrol.h ... */
>> +static inline void memcg_sock_mem_alloc(struct mem_cgroup *mem,
>> +					struct proto *prot, int amt,
>> +					int *parent_failure)
>> +{
>> +}
>
> In these days, at naming memory cgroup pointers, we use "memcg" instead of
> "mem". So, could you use "memcg" for represeinting memory cgroup ?
>
>
>> +
>> +void memcg_sock_mem_alloc(struct mem_cgroup *mem, struct proto *prot,
>> +			  int amt, int *parent_failure)
>> +{
>> +	mem = parent_mem_cgroup(mem);
>> +	for (; mem != NULL; mem = parent_mem_cgroup(mem)) {
>> +		long alloc;
>> +		long *prot_mem = prot->prot_mem(mem);
>> +		/*
>> +		 * Large nestings are not the common case, and stopping in the
>> +		 * middle would be complicated enough, that we bill it all the
>> +		 * way through the root, and if needed, unbill everything later
>> +		 */
>> +		alloc = atomic_long_add_return(amt,
>> +					       prot->memory_allocated(mem));
>> +		*parent_failure |= (alloc>  prot_mem[2]);
>> +	}
>> +}
>> +EXPORT_SYMBOL(memcg_sock_mem_alloc);
>
> Hmm. why not using res_counter ? for reusing 'unbill' code ?
>
> Thanks,
> -Kame
>
Well, besides the cost, we'd have atomic_t for !cgroups, and res_counter 
for cgroups. I think there is value in keeping them the same.

WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, paul@paulmenage.org,
	lizf@cn.fujitsu.com, ebiederm@xmission.com, davem@davemloft.net,
	gthelen@google.com, netdev@vger.kernel.org, linux-mm@kvack.org,
	kirill@shutemov.name, avagin@parallels.com
Subject: Re: [PATCH v4 3/8] foundations of per-cgroup memory pressure controlling.
Date: Tue, 4 Oct 2011 11:13:50 +0400	[thread overview]
Message-ID: <4E8AB22E.2080007@parallels.com> (raw)
In-Reply-To: <20111004095715.479da44d.kamezawa.hiroyu@jp.fujitsu.com>

On 10/04/2011 04:57 AM, KAMEZAWA Hiroyuki wrote:
> On Mon,  3 Oct 2011 14:18:38 +0400
> Glauber Costa<glommer@parallels.com>  wrote:
>
>> This patch converts struct sock fields memory_pressure,
>> memory_allocated, sockets_allocated, and sysctl_mem (now prot_mem)
>> to function pointers, receiving a struct mem_cgroup parameter.
>>
>> enter_memory_pressure is kept the same, since all its callers
>> have socket a context, and the kmem_cgroup can be derived from
>> the socket itself.
>>
>> To keep things working, the patch convert all users of those fields
>> to use acessor functions.
>>
>> In my benchmarks I didn't see a significant performance difference
>> with this patch applied compared to a baseline (around 1 % diff, thus
>> inside error margin).
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: David S. Miller<davem@davemloft.net>
>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@jp.fujitsu.com>
>> CC: Eric W. Biederman<ebiederm@xmission.com>
>
> A nitpick.
>
>
>>   #ifdef CONFIG_INET
>>   struct sock;
>> +struct proto;
>>   #ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>   void sock_update_memcg(struct sock *sk);
>>   void sock_release_memcg(struct sock *sk);
>> -
>> +void memcg_sock_mem_alloc(struct mem_cgroup *mem, struct proto *prot,
>> +			  int amt, int *parent_failure);
>> +void memcg_sock_mem_free(struct mem_cgroup *mem, struct proto *prot, int amt);
>> +void memcg_sockets_allocated_dec(struct mem_cgroup *mem, struct proto *prot);
>> +void memcg_sockets_allocated_inc(struct mem_cgroup *mem, struct proto *prot);
>>   #else
>> +/* memcontrol includes sockets.h, that includes memcontrol.h ... */
>> +static inline void memcg_sock_mem_alloc(struct mem_cgroup *mem,
>> +					struct proto *prot, int amt,
>> +					int *parent_failure)
>> +{
>> +}
>
> In these days, at naming memory cgroup pointers, we use "memcg" instead of
> "mem". So, could you use "memcg" for represeinting memory cgroup ?
>
>
>> +
>> +void memcg_sock_mem_alloc(struct mem_cgroup *mem, struct proto *prot,
>> +			  int amt, int *parent_failure)
>> +{
>> +	mem = parent_mem_cgroup(mem);
>> +	for (; mem != NULL; mem = parent_mem_cgroup(mem)) {
>> +		long alloc;
>> +		long *prot_mem = prot->prot_mem(mem);
>> +		/*
>> +		 * Large nestings are not the common case, and stopping in the
>> +		 * middle would be complicated enough, that we bill it all the
>> +		 * way through the root, and if needed, unbill everything later
>> +		 */
>> +		alloc = atomic_long_add_return(amt,
>> +					       prot->memory_allocated(mem));
>> +		*parent_failure |= (alloc>  prot_mem[2]);
>> +	}
>> +}
>> +EXPORT_SYMBOL(memcg_sock_mem_alloc);
>
> Hmm. why not using res_counter ? for reusing 'unbill' code ?
>
> Thanks,
> -Kame
>
Well, besides the cost, we'd have atomic_t for !cgroups, and res_counter 
for cgroups. I think there is value in keeping them the same.

--
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>

  parent reply	other threads:[~2011-10-04  7:14 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03 10:18 [PATCH v4 0/8] per-cgroup tcp buffer pressure settings Glauber Costa
2011-10-03 10:18 ` Glauber Costa
2011-10-03 10:18 ` [PATCH v4 1/8] Basic kernel memory functionality for the Memory Controller Glauber Costa
2011-10-03 10:18   ` Glauber Costa
2011-10-03 10:41   ` Kirill A. Shutemov
2011-10-03 10:41     ` Kirill A. Shutemov
2011-10-03 10:41     ` Glauber Costa
2011-10-03 10:41       ` Glauber Costa
2011-10-03 10:41       ` Glauber Costa
2011-10-04  0:38   ` KAMEZAWA Hiroyuki
2011-10-04  0:38     ` KAMEZAWA Hiroyuki
2011-10-03 10:18 ` [PATCH v4 2/8] socket: initial cgroup code Glauber Costa
2011-10-03 10:18   ` Glauber Costa
2011-10-03 10:47   ` Kirill A. Shutemov
2011-10-03 10:47     ` Kirill A. Shutemov
2011-10-03 10:48     ` Glauber Costa
2011-10-03 10:48       ` Glauber Costa
2011-10-03 10:48       ` Glauber Costa
2011-10-03 11:02       ` Kirill A. Shutemov
2011-10-03 11:02         ` Kirill A. Shutemov
2011-10-03 11:03         ` Glauber Costa
2011-10-03 11:03           ` Glauber Costa
2011-10-04  0:41   ` KAMEZAWA Hiroyuki
2011-10-04  0:41     ` KAMEZAWA Hiroyuki
2011-10-03 10:18 ` [PATCH v4 3/8] foundations of per-cgroup memory pressure controlling Glauber Costa
2011-10-03 10:18   ` Glauber Costa
2011-10-03 15:13   ` Andrew Vagin
2011-10-03 15:13     ` Andrew Vagin
2011-10-04  0:57   ` KAMEZAWA Hiroyuki
2011-10-04  0:57     ` KAMEZAWA Hiroyuki
2011-10-04  6:32     ` Glauber Costa
2011-10-04  6:32       ` Glauber Costa
2011-10-04  6:32       ` Glauber Costa
2011-10-04  7:13     ` Glauber Costa [this message]
2011-10-04  7:13       ` Glauber Costa
2011-10-03 10:18 ` [PATCH v4 4/8] per-cgroup tcp buffers control Glauber Costa
2011-10-03 10:18   ` Glauber Costa
2011-10-04  1:16   ` KAMEZAWA Hiroyuki
2011-10-04  1:16     ` KAMEZAWA Hiroyuki
2011-10-04  5:43     ` Glauber Costa
2011-10-04  5:43       ` Glauber Costa
2011-10-04  5:43       ` Glauber Costa
2011-10-03 10:18 ` [PATCH v4 5/8] per-netns ipv4 sysctl_tcp_mem Glauber Costa
2011-10-03 10:18   ` Glauber Costa
2011-10-04  1:18   ` KAMEZAWA Hiroyuki
2011-10-04  1:18     ` KAMEZAWA Hiroyuki
2011-10-03 10:18 ` [PATCH v4 6/8] tcp buffer limitation: per-cgroup limit Glauber Costa
2011-10-03 10:18   ` Glauber Costa
2011-10-04  1:21   ` KAMEZAWA Hiroyuki
2011-10-04  1:21     ` KAMEZAWA Hiroyuki
2011-10-04  6:22     ` Glauber Costa
2011-10-04  6:22       ` Glauber Costa
2011-10-04  6:22       ` Glauber Costa
2011-10-03 10:18 ` [PATCH v4 7/8] Display current tcp memory allocation in kmem cgroup Glauber Costa
2011-10-03 10:18   ` Glauber Costa
2011-10-03 12:14   ` Kirill A. Shutemov
2011-10-03 12:14     ` Kirill A. Shutemov
2011-10-03 12:19     ` Glauber Costa
2011-10-03 12:19       ` Glauber Costa
2011-10-03 12:19       ` Glauber Costa
2011-10-03 12:25       ` Kirill A. Shutemov
2011-10-03 12:25         ` Kirill A. Shutemov
2011-10-03 12:26         ` Glauber Costa
2011-10-03 12:26           ` Glauber Costa
2011-10-03 12:26           ` Glauber Costa
2011-10-03 12:36           ` Kirill A. Shutemov
2011-10-03 12:36             ` Kirill A. Shutemov
2011-10-03 12:36             ` Glauber Costa
2011-10-03 12:36               ` Glauber Costa
2011-10-03 12:36               ` Glauber Costa
2011-10-04  9:10             ` Glauber Costa
2011-10-04  9:10               ` Glauber Costa
2011-10-04  9:10               ` Glauber Costa
2011-10-06  8:46               ` Kirill A. Shutemov
2011-10-06  8:46                 ` Kirill A. Shutemov
2011-10-03 10:18 ` [PATCH v4 8/8] Disable task moving when using kernel memory accounting Glauber Costa
2011-10-03 10:18   ` Glauber Costa

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=4E8AB22E.2080007@parallels.com \
    --to=glommer@parallels.com \
    --cc=avagin@parallels.com \
    --cc=davem@davemloft.net \
    --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.