All of lore.kernel.org
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: David Rientjes <rientjes@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Gao feng <gaofeng@cn.fujitsu.com>,
	hannes@cmpxchg.org, mhocko@suse.cz, bsingharora@gmail.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	containers@lists.linux-foundation.org
Subject: Re: [PATCH] meminfo: show /proc/meminfo base on container's memcg
Date: Thu, 31 May 2012 03:42:38 -0400	[thread overview]
Message-ID: <4FC720EE.3010307@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205310028420.8864@chino.kir.corp.google.com>

(5/31/12 3:35 AM), David Rientjes wrote:
> On Thu, 31 May 2012, KOSAKI Motohiro wrote:
>
>>> As I said, LXC and namespace isolation is a tangent to the discussion of
>>> faking the /proc/meminfo for the memcg context of a thread.
>>
>> Because of, /proc/meminfo affect a lot of libraries behavior. So, it's not only
>> application issue. If you can't rewrite _all_ of userland assets, fake meminfo
>> can't be escaped. Again see alternative container implementation.
>>
>
> It's a tangent because it isn't a complete psuedo /proc/meminfo for all
> threads attached to a memcg regardless of any namespace isolation; the LXC
> solution has existed for a couple of years by its procfs patchset that
> overlaps procfs with fuse and can suppress or modify any output in the
> context of a memory controller using things like
> memory.{limit,usage}_in_bytes.  I'm sure all other fields could be
> modified if outputted in some structured way via memcg; it looks like
> memory.stat would need to be extended to provide that.  If that's mounted
> prior to executing the application, then your isolation is achieved and
> all libraries should see the new output that you've defined in LXC.
>
> However, this seems like a seperate topic than the patch at hand which
> does this directly to /proc/meminfo based on a thread's memcg context,
> that's the part that I'm nacking.

Then, I NAKed current patch too. Yeah, current one is ugly. It assume _all_
user need namespace isolation and it clearly is not.


> I'd recommend to Gao to expose this
> information via memory.stat and then use fuse and the procfs lxc support
> as your way of contextualizing the resources.

It's one of a option. But, I seriously doubt fuse can make simpler than kamezawa-san's
idea. But yeah, I might NACK kamezawa-san's one if he will post ugly patch.


--
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: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: David Rientjes <rientjes@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Gao feng <gaofeng@cn.fujitsu.com>,
	hannes@cmpxchg.org, mhocko@suse.cz, bsingharora@gmail.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	containers@lists.linux-foundation.org
Subject: Re: [PATCH] meminfo: show /proc/meminfo base on container's memcg
Date: Thu, 31 May 2012 03:42:38 -0400	[thread overview]
Message-ID: <4FC720EE.3010307@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205310028420.8864@chino.kir.corp.google.com>

(5/31/12 3:35 AM), David Rientjes wrote:
> On Thu, 31 May 2012, KOSAKI Motohiro wrote:
>
>>> As I said, LXC and namespace isolation is a tangent to the discussion of
>>> faking the /proc/meminfo for the memcg context of a thread.
>>
>> Because of, /proc/meminfo affect a lot of libraries behavior. So, it's not only
>> application issue. If you can't rewrite _all_ of userland assets, fake meminfo
>> can't be escaped. Again see alternative container implementation.
>>
>
> It's a tangent because it isn't a complete psuedo /proc/meminfo for all
> threads attached to a memcg regardless of any namespace isolation; the LXC
> solution has existed for a couple of years by its procfs patchset that
> overlaps procfs with fuse and can suppress or modify any output in the
> context of a memory controller using things like
> memory.{limit,usage}_in_bytes.  I'm sure all other fields could be
> modified if outputted in some structured way via memcg; it looks like
> memory.stat would need to be extended to provide that.  If that's mounted
> prior to executing the application, then your isolation is achieved and
> all libraries should see the new output that you've defined in LXC.
>
> However, this seems like a seperate topic than the patch at hand which
> does this directly to /proc/meminfo based on a thread's memcg context,
> that's the part that I'm nacking.

Then, I NAKed current patch too. Yeah, current one is ugly. It assume _all_
user need namespace isolation and it clearly is not.


> I'd recommend to Gao to expose this
> information via memory.stat and then use fuse and the procfs lxc support
> as your way of contextualizing the resources.

It's one of a option. But, I seriously doubt fuse can make simpler than kamezawa-san's
idea. But yeah, I might NACK kamezawa-san's one if he will post ugly patch.


--
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: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: David Rientjes <rientjes@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Gao feng <gaofeng@cn.fujitsu.com>,
	hannes@cmpxchg.org, mhocko@suse.cz, bsingharora@gmail.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	containers@lists.linux-foundation.org
Subject: Re: [PATCH] meminfo: show /proc/meminfo base on container's memcg
Date: Thu, 31 May 2012 03:42:38 -0400	[thread overview]
Message-ID: <4FC720EE.3010307@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205310028420.8864@chino.kir.corp.google.com>

(5/31/12 3:35 AM), David Rientjes wrote:
> On Thu, 31 May 2012, KOSAKI Motohiro wrote:
>
>>> As I said, LXC and namespace isolation is a tangent to the discussion of
>>> faking the /proc/meminfo for the memcg context of a thread.
>>
>> Because of, /proc/meminfo affect a lot of libraries behavior. So, it's not only
>> application issue. If you can't rewrite _all_ of userland assets, fake meminfo
>> can't be escaped. Again see alternative container implementation.
>>
>
> It's a tangent because it isn't a complete psuedo /proc/meminfo for all
> threads attached to a memcg regardless of any namespace isolation; the LXC
> solution has existed for a couple of years by its procfs patchset that
> overlaps procfs with fuse and can suppress or modify any output in the
> context of a memory controller using things like
> memory.{limit,usage}_in_bytes.  I'm sure all other fields could be
> modified if outputted in some structured way via memcg; it looks like
> memory.stat would need to be extended to provide that.  If that's mounted
> prior to executing the application, then your isolation is achieved and
> all libraries should see the new output that you've defined in LXC.
>
> However, this seems like a seperate topic than the patch at hand which
> does this directly to /proc/meminfo based on a thread's memcg context,
> that's the part that I'm nacking.

Then, I NAKed current patch too. Yeah, current one is ugly. It assume _all_
user need namespace isolation and it clearly is not.


> I'd recommend to Gao to expose this
> information via memory.stat and then use fuse and the procfs lxc support
> as your way of contextualizing the resources.

It's one of a option. But, I seriously doubt fuse can make simpler than kamezawa-san's
idea. But yeah, I might NACK kamezawa-san's one if he will post ugly patch.



  parent reply	other threads:[~2012-05-31  7:42 UTC|newest]

Thread overview: 113+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-29  2:56 [PATCH] meminfo: show /proc/meminfo base on container's memcg Gao feng
2012-05-29  2:56 ` Gao feng
     [not found] ` <1338260214-21919-1-git-send-email-gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2012-05-29  8:24   ` Glauber Costa
2012-05-29  8:24   ` Glauber Costa
2012-05-29  8:24     ` Glauber Costa
2012-05-29  8:24     ` Glauber Costa
2012-05-30 21:38   ` David Rientjes
2012-05-30 21:38   ` David Rientjes
2012-05-30 21:38     ` David Rientjes
2012-05-30 21:38     ` David Rientjes
2012-05-30 23:20     ` Kirill A. Shutemov
2012-05-30 23:20       ` Kirill A. Shutemov
     [not found]       ` <20120530232004.GA15423-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
2012-05-31  0:35         ` David Rientjes
2012-05-31  0:35           ` David Rientjes
2012-05-31  0:35           ` David Rientjes
     [not found]     ` <alpine.DEB.2.00.1205301433490.9716-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-05-30 23:20       ` Kirill A. Shutemov
2012-05-31  0:08       ` Kamezawa Hiroyuki
2012-05-31  0:08         ` Kamezawa Hiroyuki
2012-05-31  0:08         ` Kamezawa Hiroyuki
     [not found]         ` <4FC6B68C.2070703-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-05-31  0:22           ` KOSAKI Motohiro
2012-05-31  0:22             ` KOSAKI Motohiro
2012-05-31  0:22             ` KOSAKI Motohiro
     [not found]             ` <CAHGf_=pFbsy4FO_UNu6O1-KyTd6O=pkmR8=3EGuZB5Reu3Vb9w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-05-31  0:33               ` Kamezawa Hiroyuki
2012-05-31  0:33               ` Kamezawa Hiroyuki
2012-05-31  0:33                 ` Kamezawa Hiroyuki
2012-05-31  0:33                 ` Kamezawa Hiroyuki
     [not found]                 ` <4FC6BC3E.5010807-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-05-31  0:44                   ` David Rientjes
2012-05-31  0:44                   ` David Rientjes
2012-05-31  0:44                     ` David Rientjes
2012-05-31  0:44                     ` David Rientjes
2012-05-31  0:53                     ` Kamezawa Hiroyuki
2012-05-31  0:53                       ` Kamezawa Hiroyuki
     [not found]                       ` <4FC6C111.2060108-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-05-31  1:31                         ` David Rientjes
2012-05-31  1:31                           ` David Rientjes
2012-05-31  1:31                           ` David Rientjes
     [not found]                           ` <alpine.DEB.2.00.1205301831270.25774-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-05-31  2:33                             ` Kamezawa Hiroyuki
2012-05-31  2:33                               ` Kamezawa Hiroyuki
2012-05-31  2:33                               ` Kamezawa Hiroyuki
     [not found]                               ` <4FC6D881.4090706-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-05-31  5:02                                 ` David Rientjes
2012-05-31  5:02                               ` David Rientjes
2012-05-31  5:02                                 ` David Rientjes
     [not found]                                 ` <alpine.DEB.2.00.1205302156090.25774-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-05-31  5:36                                   ` Kamezawa Hiroyuki
2012-05-31  5:36                                 ` Kamezawa Hiroyuki
2012-05-31  5:36                                   ` Kamezawa Hiroyuki
     [not found]                                   ` <4FC70355.70805-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-05-31  6:17                                     ` David Rientjes
2012-05-31  6:17                                       ` David Rientjes
2012-05-31  6:17                                       ` David Rientjes
     [not found]                                       ` <alpine.DEB.2.00.1205302314190.25774-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-05-31  6:23                                         ` KOSAKI Motohiro
2012-05-31  6:23                                           ` KOSAKI Motohiro
2012-05-31  6:23                                           ` KOSAKI Motohiro
     [not found]                                           ` <4FC70E5E.1010003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-05-31  6:28                                             ` David Rientjes
2012-05-31  6:28                                               ` David Rientjes
2012-05-31  6:28                                               ` David Rientjes
     [not found]                                               ` <alpine.DEB.2.00.1205302325500.25774-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-05-31  6:37                                                 ` KOSAKI Motohiro
2012-05-31  6:37                                                   ` KOSAKI Motohiro
2012-05-31  6:37                                                   ` KOSAKI Motohiro
     [not found]                                                   ` <4FC711A5.4090003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-05-31  6:56                                                     ` David Rientjes
2012-05-31  6:56                                                       ` David Rientjes
2012-05-31  6:56                                                       ` David Rientjes
     [not found]                                                       ` <alpine.DEB.2.00.1205302351510.25774-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-05-31  7:09                                                         ` KOSAKI Motohiro
2012-05-31  7:09                                                           ` KOSAKI Motohiro
2012-05-31  7:09                                                           ` KOSAKI Motohiro
     [not found]                                                           ` <CAHGf_=qVDVT6VW2j9gE3bQKwizW24iivrDryiCKoxVu4m_fWKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-05-31  7:35                                                             ` David Rientjes
2012-05-31  7:35                                                             ` David Rientjes
2012-05-31  7:35                                                               ` David Rientjes
2012-05-31  7:35                                                               ` David Rientjes
     [not found]                                                               ` <alpine.DEB.2.00.1205310028420.8864-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-05-31  7:42                                                                 ` KOSAKI Motohiro
2012-05-31  7:42                                                               ` KOSAKI Motohiro [this message]
2012-05-31  7:42                                                                 ` KOSAKI Motohiro
2012-05-31  7:42                                                                 ` KOSAKI Motohiro
     [not found]                                                                 ` <4FC720EE.3010307-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-05-31  7:57                                                                   ` Johannes Weiner
2012-05-31  7:57                                                                     ` Johannes Weiner
2012-05-31  7:57                                                                     ` Johannes Weiner
2012-05-31  7:57                                                                   ` Johannes Weiner
2012-05-31  7:58                                                                   ` Gao feng
2012-05-31  7:58                                                                   ` Gao feng
2012-05-31  7:58                                                                     ` Gao feng
2012-05-31  7:58                                                                     ` Gao feng
2012-05-31  8:32                                                                     ` Glauber Costa
2012-05-31  8:32                                                                       ` Glauber Costa
2012-05-31  8:32                                                                       ` Glauber Costa
     [not found]                                                                       ` <4FC72CA4.6080708-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-05-31  8:51                                                                         ` Kamezawa Hiroyuki
2012-05-31  8:51                                                                           ` Kamezawa Hiroyuki
2012-05-31  8:51                                                                           ` Kamezawa Hiroyuki
     [not found]                                                                           ` <4FC73110.6010107-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-05-31  8:59                                                                             ` Glauber Costa
2012-05-31  8:59                                                                               ` Glauber Costa
2012-05-31  8:59                                                                               ` Glauber Costa
2012-05-31  8:51                                                                         ` Kamezawa Hiroyuki
2012-05-31  8:55                                                                         ` Gao feng
2012-05-31  8:55                                                                       ` Gao feng
2012-05-31  8:55                                                                         ` Gao feng
2012-05-31  8:55                                                                         ` Gao feng
     [not found]                                                                         ` <4FC73203.2070009-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2012-05-31  8:56                                                                           ` Glauber Costa
2012-05-31  8:56                                                                           ` Glauber Costa
2012-05-31  8:56                                                                             ` Glauber Costa
2012-05-31  8:56                                                                             ` Glauber Costa
     [not found]                                                                     ` <4FC724B1.70508-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2012-05-31  8:32                                                                       ` Glauber Costa
2012-05-31  7:07                                                     ` Kamezawa Hiroyuki
2012-05-31  7:07                                                     ` Kamezawa Hiroyuki
2012-05-31  7:07                                                       ` Kamezawa Hiroyuki
2012-05-31  7:07                                                       ` Kamezawa Hiroyuki
     [not found]                                                       ` <4FC718BA.8060608-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-05-31  7:23                                                         ` KOSAKI Motohiro
2012-05-31  7:23                                                           ` KOSAKI Motohiro
2012-05-31  7:23                                                           ` KOSAKI Motohiro
2012-05-31  8:29                                         ` Glauber Costa
2012-05-31  8:29                                           ` Glauber Costa
2012-05-31  8:29                                           ` Glauber Costa
     [not found]                     ` <alpine.DEB.2.00.1205301737530.25774-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-05-31  0:53                       ` Kamezawa Hiroyuki
2012-05-31  0:22           ` KOSAKI Motohiro
2012-06-07 23:18   ` Zhu Yanhai
2012-06-07 23:18     ` Zhu Yanhai
2012-06-07 23:18     ` Zhu Yanhai
  -- strict thread matches above, loose matches on Subject: below --
2012-05-29  2:56 Gao feng

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=4FC720EE.3010307@gmail.com \
    --to=kosaki.motohiro@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bsingharora@gmail.com \
    --cc=cgroups@vger.kernel.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=gaofeng@cn.fujitsu.com \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=rientjes@google.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.