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. 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.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>