Hey, On Mon, Apr 22, 2013 at 05:54:54PM +0200, Michal Hocko wrote: > > Oh, if so, I'm happy. Sorry about being brash on the thread; however, > > please talk with google memcg people. They have very different > > interpretation of what "softlimit" is and are using it according to > > that interpretation. If it *is* an actual soft limit, there is no > > inherent isolation coming from it and that should be clear to > > everyone. > > We have discussed that for a long time. I will not speak for Greg & Ying > but from my POV we have agreed that the current implementation will work > for them with some (minor) changes in their layout. > As I have said already with a careful configuration (e.i. setting the > soft limit only where it matters - where it protects an important > memory which is usually in the leaf nodes) you can actually achieve > _high_ probability for not being reclaimed after the rework which was not > possible before because of the implementation which was ugly and > smelled. I don't know. I'm not sure this is a good idea. It's still encouraging abuse of the knob even if that's not the intention and once the usage sticks you end up with something you can't revert afterwards. I think it'd be better to make it *very* clear that "softlimit" can't be used for isolation in any reliable way. Thanks. -- tejun -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>