On 02/15/2013 05:28 AM, Greg Thelen wrote: > On Fri, Feb 08 2013, Glauber Costa wrote: > >> This patchset implements targeted shrinking for memcg when kmem limits are >> present. So far, we've been accounting kernel objects but failing allocations >> when short of memory. This is because our only option would be to call the >> global shrinker, depleting objects from all caches and breaking isolation. >> >> This patchset builds upon the recent work from David Chinner >> (http://oss.sgi.com/archives/xfs/2012-11/msg00643.html) to implement NUMA >> aware per-node LRUs. I build heavily on its API, and its presence is implied. >> >> The main idea is to associate per-memcg lists with each of the LRUs. The main >> LRU still provides a single entry point and when adding or removing an element >> from the LRU, we use the page information to figure out which memcg it belongs >> to and relay it to the right list. >> >> This patchset is still not perfect, and some uses cases still need to be >> dealt with. But I wanted to get this out in the open sooner rather than >> later. In particular, I have the following (noncomprehensive) todo list: >> >> TODO: >> * shrink dead memcgs when global pressure kicks in. >> * balance global reclaim among memcgs. >> * improve testing and reliability (I am still seeing some stalls in some cases) > > Do you have a git tree with these changes so I can see Dave's numa LRUs > plus these changes? > I've just uploaded the exact same thing I have sent here to: git://git.kernel.org/pub/scm/linux/kernel/git/glommer/memcg.git The branch is kmemcg-lru-shrinker. Note that there is also another branch kmemcg-shrinker that contains some other simple patches that were not yet taken and are more stable. I eventually have to merge the two. I also still need to incorporate the feedback from you and Kame into that. I will be traveling until next Wednesday, so expect changes in there around Thursday. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
