> From: KAMEZAWA Hiroyuki [mailto:kamezawa.hiroyu@xxxxxxxxxxxxxx] > Subject: Re: Subject: [PATCH V7 2/4] mm: frontswap: core code > > On Thu, 25 Aug 2011 10:37:05 -0700 (PDT) > Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote: > > > > From: KAMEZAWA Hiroyuki [mailto:kamezawa.hiroyu@xxxxxxxxxxxxxx] > > > Subject: Re: Subject: [PATCH V7 2/4] mm: frontswap: core code > > > > BTW, Do I have a chance to implement frontswap accounting per cgroup > > > (under memcg) ? Or Do I need to enable/disale switch for frontswap per memcg ? > > > Do you think it is worth to do ? > > > > I'm not very familiar with cgroups or memcg but I think it may be possible > > to implement transcendent memory with cgroup as the "guest" and the default > > cgroup as the "host" to allow for more memory elasticity for cgroups. > > (See http://lwn.net/Articles/454795/ for a good overview of all of > > transcendent memory.) > > > Ok, I'll see it. > > I just wonder following case. > > Assume 2 memcgs. > memcg X: memory limit = 300M. > memcg Y: memory limit = 300M. > > This limitation is done for performance isolation. > When using frontswap, X and Y can cause resource confliction in frontswap and > performance of X and Y cannot be predictable. Oops, sorry for the extra reply, but I realize I cut/paste to reply to this part and neglected to reply. IMHO, it is impossible to do both dynamic resource optimization and performance isolation. So if the purpose of containers is for performance isolation you need to partition ALL resources, including CPUs (and not even split threads) and I/O devices. And even then there will be unpredictable use of some shared system resource (such as maybe a QPI link or PCI bus). If you are not partitioning all resources, then RAM is just another resource that should be dynamically optimized which may result in performance variations. With strict policies, maybe some quality-of-service guarantees can be made. But that's just my opinion... Dan -- 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