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, devel@openvz.org,
	eric.dumazet@gmail.com, cgroups@vger.kernel.org
Subject: Re: [PATCH v7 02/10] foundations of per-cgroup memory pressure controlling.
Date: Fri, 2 Dec 2011 15:46:46 -0200	[thread overview]
Message-ID: <4ED90F06.102@parallels.com> (raw)
In-Reply-To: <20111130094305.9c69ecd8.kamezawa.hiroyu@jp.fujitsu.com>


>>   static void proto_seq_printf(struct seq_file *seq, struct proto *proto)
>>   {
>> +	struct mem_cgroup *memcg = mem_cgroup_from_task(current);
>> +
>>   	seq_printf(seq, "%-9s %4u %6d  %6ld   %-3s %6u   %-3s  %-10s "
>>   			"%2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c\n",
>>   		   proto->name,
>>   		   proto->obj_size,
>>   		   sock_prot_inuse_get(seq_file_net(seq), proto),
>> -		   proto->memory_allocated != NULL ? atomic_long_read(proto->memory_allocated) : -1L,
>> -		   proto->memory_pressure != NULL ? *proto->memory_pressure ? "yes" : "no" : "NI",
>> +		   sock_prot_memory_allocated(proto, memcg),
>> +		   sock_prot_memory_pressure(proto, memcg),
>
> I wonder I should say NO, here. (Networking guys are ok ??)
>
> IIUC, this means there is no way to see aggregated sockstat of all system.
> And the result depends on the cgroup which the caller is under control.
>
> I think you should show aggregated sockstat(global + per-memcg) here and
> show per-memcg ones via /cgroup interface or add private_sockstat to show
> per cgroup summary.
>

Hi Kame,

Yes, the statistics displayed depends on which cgroup you live.
Also, note that the parent cgroup here is always updated (even when 
use_hierarchy is set to 0). So it is always possible to grab global 
statistics, by being in the root cgroup.

For the others, I believe it to be a question of naturalization. Any 
tool that is fetching these values is likely interested in the amount of 
resources available/used. When you are on a cgroup, the amount of 
resources available/used changes, so that's what you should see.

Also brings the point of resource isolation: if you shouldn't interfere 
with other set of process' resources, there is no reason for you to see 
them in the first place.

So given all that, I believe that whenever we talk about resources in a 
cgroup, we should talk about cgroup-local ones.

--
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: 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>,
	<devel@openvz.org>, <eric.dumazet@gmail.com>,
	<cgroups@vger.kernel.org>
Subject: Re: [PATCH v7 02/10] foundations of per-cgroup memory pressure controlling.
Date: Fri, 2 Dec 2011 15:46:46 -0200	[thread overview]
Message-ID: <4ED90F06.102@parallels.com> (raw)
In-Reply-To: <20111130094305.9c69ecd8.kamezawa.hiroyu@jp.fujitsu.com>


>>   static void proto_seq_printf(struct seq_file *seq, struct proto *proto)
>>   {
>> +	struct mem_cgroup *memcg = mem_cgroup_from_task(current);
>> +
>>   	seq_printf(seq, "%-9s %4u %6d  %6ld   %-3s %6u   %-3s  %-10s "
>>   			"%2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c\n",
>>   		   proto->name,
>>   		   proto->obj_size,
>>   		   sock_prot_inuse_get(seq_file_net(seq), proto),
>> -		   proto->memory_allocated != NULL ? atomic_long_read(proto->memory_allocated) : -1L,
>> -		   proto->memory_pressure != NULL ? *proto->memory_pressure ? "yes" : "no" : "NI",
>> +		   sock_prot_memory_allocated(proto, memcg),
>> +		   sock_prot_memory_pressure(proto, memcg),
>
> I wonder I should say NO, here. (Networking guys are ok ??)
>
> IIUC, this means there is no way to see aggregated sockstat of all system.
> And the result depends on the cgroup which the caller is under control.
>
> I think you should show aggregated sockstat(global + per-memcg) here and
> show per-memcg ones via /cgroup interface or add private_sockstat to show
> per cgroup summary.
>

Hi Kame,

Yes, the statistics displayed depends on which cgroup you live.
Also, note that the parent cgroup here is always updated (even when 
use_hierarchy is set to 0). So it is always possible to grab global 
statistics, by being in the root cgroup.

For the others, I believe it to be a question of naturalization. Any 
tool that is fetching these values is likely interested in the amount of 
resources available/used. When you are on a cgroup, the amount of 
resources available/used changes, so that's what you should see.

Also brings the point of resource isolation: if you shouldn't interfere 
with other set of process' resources, there is no reason for you to see 
them in the first place.

So given all that, I believe that whenever we talk about resources in a 
cgroup, we should talk about cgroup-local ones.

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>,
	<devel@openvz.org>, <eric.dumazet@gmail.com>,
	<cgroups@vger.kernel.org>
Subject: Re: [PATCH v7 02/10] foundations of per-cgroup memory pressure controlling.
Date: Fri, 2 Dec 2011 15:46:46 -0200	[thread overview]
Message-ID: <4ED90F06.102@parallels.com> (raw)
In-Reply-To: <20111130094305.9c69ecd8.kamezawa.hiroyu@jp.fujitsu.com>


>>   static void proto_seq_printf(struct seq_file *seq, struct proto *proto)
>>   {
>> +	struct mem_cgroup *memcg = mem_cgroup_from_task(current);
>> +
>>   	seq_printf(seq, "%-9s %4u %6d  %6ld   %-3s %6u   %-3s  %-10s "
>>   			"%2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c\n",
>>   		   proto->name,
>>   		   proto->obj_size,
>>   		   sock_prot_inuse_get(seq_file_net(seq), proto),
>> -		   proto->memory_allocated != NULL ? atomic_long_read(proto->memory_allocated) : -1L,
>> -		   proto->memory_pressure != NULL ? *proto->memory_pressure ? "yes" : "no" : "NI",
>> +		   sock_prot_memory_allocated(proto, memcg),
>> +		   sock_prot_memory_pressure(proto, memcg),
>
> I wonder I should say NO, here. (Networking guys are ok ??)
>
> IIUC, this means there is no way to see aggregated sockstat of all system.
> And the result depends on the cgroup which the caller is under control.
>
> I think you should show aggregated sockstat(global + per-memcg) here and
> show per-memcg ones via /cgroup interface or add private_sockstat to show
> per cgroup summary.
>

Hi Kame,

Yes, the statistics displayed depends on which cgroup you live.
Also, note that the parent cgroup here is always updated (even when 
use_hierarchy is set to 0). So it is always possible to grab global 
statistics, by being in the root cgroup.

For the others, I believe it to be a question of naturalization. Any 
tool that is fetching these values is likely interested in the amount of 
resources available/used. When you are on a cgroup, the amount of 
resources available/used changes, so that's what you should see.

Also brings the point of resource isolation: if you shouldn't interfere 
with other set of process' resources, there is no reason for you to see 
them in the first place.

So given all that, I believe that whenever we talk about resources in a 
cgroup, we should talk about cgroup-local ones.

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

  reply	other threads:[~2011-12-02 17:46 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29 23:56 [PATCH v7 00/10] Request for Inclusion: per-cgroup tcp memory pressure Glauber Costa
2011-11-29 23:56 ` Glauber Costa
2011-11-29 23:56 ` [PATCH v7 01/10] Basic kernel memory functionality for the Memory Controller Glauber Costa
2011-11-29 23:56   ` Glauber Costa
     [not found]   ` <1322611021-1730-2-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30  0:48     ` KAMEZAWA Hiroyuki
2011-11-30  0:48       ` KAMEZAWA Hiroyuki
2011-11-30  0:48       ` KAMEZAWA Hiroyuki
2011-11-29 23:56 ` [PATCH v7 02/10] foundations of per-cgroup memory pressure controlling Glauber Costa
2011-11-29 23:56   ` Glauber Costa
2011-11-30  0:43   ` KAMEZAWA Hiroyuki
2011-11-30  0:43     ` KAMEZAWA Hiroyuki
2011-12-02 17:46     ` Glauber Costa [this message]
2011-12-02 17:46       ` Glauber Costa
2011-12-02 17:46       ` Glauber Costa
2011-12-05  1:59       ` KAMEZAWA Hiroyuki
2011-12-05  1:59         ` KAMEZAWA Hiroyuki
2011-12-05  1:59         ` KAMEZAWA Hiroyuki
2011-12-05  9:06         ` Glauber Costa
2011-12-05  9:06           ` Glauber Costa
2011-12-05  9:06           ` Glauber Costa
2011-11-29 23:56 ` [PATCH v7 03/10] socket: initial cgroup code Glauber Costa
2011-11-29 23:56   ` Glauber Costa
     [not found]   ` <1322611021-1730-4-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30  1:07     ` KAMEZAWA Hiroyuki
2011-11-30  1:07       ` KAMEZAWA Hiroyuki
2011-11-30  1:07       ` KAMEZAWA Hiroyuki
2011-11-29 23:56 ` [PATCH v7 04/10] tcp memory pressure controls Glauber Costa
2011-11-29 23:56   ` Glauber Costa
     [not found]   ` <1322611021-1730-5-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30  1:49     ` KAMEZAWA Hiroyuki
2011-11-30  1:49       ` KAMEZAWA Hiroyuki
2011-11-30  1:49       ` KAMEZAWA Hiroyuki
     [not found]       ` <20111130104943.d9b210ee.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-12-02 17:57         ` Glauber Costa
2011-12-02 17:57           ` Glauber Costa
2011-12-02 17:57           ` Glauber Costa
2011-12-02 17:57           ` Glauber Costa
     [not found]           ` <4ED91188.6030503-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-05  2:01             ` KAMEZAWA Hiroyuki
2011-12-05  2:01               ` KAMEZAWA Hiroyuki
2011-12-05  2:01               ` KAMEZAWA Hiroyuki
2011-12-05  2:01               ` KAMEZAWA Hiroyuki
2011-11-29 23:56 ` [PATCH v7 05/10] per-netns ipv4 sysctl_tcp_mem Glauber Costa
2011-11-29 23:56   ` Glauber Costa
2011-11-29 23:56 ` [PATCH v7 06/10] tcp buffer limitation: per-cgroup limit Glauber Costa
2011-11-29 23:56   ` Glauber Costa
     [not found]   ` <1322611021-1730-7-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30  2:00     ` KAMEZAWA Hiroyuki
2011-11-30  2:00       ` KAMEZAWA Hiroyuki
2011-11-30  2:00       ` KAMEZAWA Hiroyuki
2011-11-29 23:56 ` [PATCH v7 07/10] Display current tcp memory allocation in kmem cgroup Glauber Costa
2011-11-29 23:56   ` Glauber Costa
2011-11-29 23:56 ` [PATCH v7 08/10] Display current tcp failcnt " Glauber Costa
2011-11-29 23:56   ` Glauber Costa
2011-11-30  2:01   ` KAMEZAWA Hiroyuki
2011-11-30  2:01     ` KAMEZAWA Hiroyuki
2011-11-29 23:57 ` [PATCH v7 09/10] Display maximum tcp memory allocation " Glauber Costa
2011-11-29 23:57   ` Glauber Costa
     [not found]   ` <1322611021-1730-10-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30  2:02     ` KAMEZAWA Hiroyuki
2011-11-30  2:02       ` KAMEZAWA Hiroyuki
2011-11-30  2:02       ` KAMEZAWA Hiroyuki
2011-11-29 23:57 ` [PATCH v7 10/10] Disable task moving when using kernel memory accounting Glauber Costa
2011-11-29 23:57   ` Glauber Costa
     [not found]   ` <1322611021-1730-11-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30  2:22     ` KAMEZAWA Hiroyuki
2011-11-30  2:22       ` KAMEZAWA Hiroyuki
2011-11-30  2:22       ` KAMEZAWA Hiroyuki
     [not found]       ` <20111130112210.1d979512.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-12-02 18:11         ` Glauber Costa
2011-12-02 18:11           ` Glauber Costa
2011-12-02 18:11           ` Glauber Costa
2011-12-02 18:11           ` Glauber Costa
     [not found]           ` <4ED914EC.6020500-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-05  2:18             ` KAMEZAWA Hiroyuki
2011-12-05  2:18               ` KAMEZAWA Hiroyuki
2011-12-05  2:18               ` KAMEZAWA Hiroyuki
2011-12-05  2:18               ` KAMEZAWA Hiroyuki
2011-12-05  9:18               ` Glauber Costa
2011-12-05  9:18                 ` Glauber Costa
2011-12-05  9:18                 ` Glauber Costa
     [not found]                 ` <4EDC8C6D.2070001-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-06  0:07                   ` KAMEZAWA Hiroyuki
2011-12-06  0:07                     ` KAMEZAWA Hiroyuki
2011-12-06  0:07                     ` KAMEZAWA Hiroyuki
2011-12-06  0:07                     ` KAMEZAWA Hiroyuki
     [not found] ` <1322611021-1730-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-30  2:11   ` [PATCH v7 00/10] Request for Inclusion: per-cgroup tcp memory pressure KAMEZAWA Hiroyuki
2011-11-30  2:11     ` KAMEZAWA Hiroyuki
2011-11-30  2:11     ` KAMEZAWA Hiroyuki
     [not found]     ` <20111130111152.6b1c7366.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-12-02 18:04       ` Glauber Costa
2011-12-02 18:04         ` Glauber Costa
2011-12-02 18:04         ` Glauber Costa
2011-12-02 18:04         ` Glauber Costa
     [not found]         ` <4ED91318.1030803-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-05  2:06           ` KAMEZAWA Hiroyuki
2011-12-05  2:06             ` KAMEZAWA Hiroyuki
2011-12-05  2:06             ` KAMEZAWA Hiroyuki
2011-12-05  2:06             ` KAMEZAWA Hiroyuki
2011-12-05  9:09             ` Glauber Costa
2011-12-05  9:09               ` Glauber Costa
2011-12-05  9:09               ` Glauber Costa
     [not found]               ` <4EDC8A5F.8040402-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-05  9:51                 ` KAMEZAWA Hiroyuki
2011-12-05  9:51                   ` KAMEZAWA Hiroyuki
2011-12-05  9:51                   ` KAMEZAWA Hiroyuki
2011-12-05  9:51                   ` KAMEZAWA Hiroyuki
2011-12-05 10:28                   ` Glauber Costa
2011-12-05 10:28                     ` Glauber Costa
2011-12-05 10:28                     ` 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=4ED90F06.102@parallels.com \
    --to=glommer@parallels.com \
    --cc=avagin@parallels.com \
    --cc=cgroups@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=devel@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=eric.dumazet@gmail.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.