On Fri, May 06, 2011 at 02:28:34PM +0900, KAMEZAWA Hiroyuki wrote: > Hmm, so, the interface should be > > memory.watermark --- the total usage which kernel's memory shrinker starts. > > ? > > I'm okay with this. And I think this parameter should be fully independent from > the limit. > > Memcg can work without watermark reclaim. I think my patch just adds a new > _limit_ which a user can shrink usage of memory on deamand with kernel's help. > Memory reclaim works in background but this is not a kswapd, at all. > > I guess performance benefit of using watermark under a cgroup which has limit > is very small and I think this is not for a performance tuning parameter. > This is just a new limit. > > Comparing 2 cases, > > cgroup A) > - has limit of 300M, no watermaks. > cgroup B) > - has limit of UNLIMITED, watermarks=300M > > A) has hard limit and memory reclaim cost is paid by user threads, and have > risks of OOM under memcg. > B) has no hard limit and memory reclaim cost is paid by kernel threads, and > will not have risk of OOM under memcg, but can be CPU burning. > > I think this should be called as soft-limit ;) But we have another soft-limit now. > Then, I call this as watermark. This will be useful to resize usage of memory > in online because application will not hit limit and get big latency even while > an admin makes watermark smaller. I have two thoughts to this: 1. Even though the memcg will not hit the limit and the application will not be forced to do memcg target reclaim, the watermark reclaim will steal pages from the memcg and the application will suffer the page faults, so it's not an unconditional win. 2. I understand how the feature is supposed to work, but I don't understand or see a use case for the watermark being configurable. Don't get me wrong, I completely agree with watermark reclaim, it's a good latency optimization. But I don't see why you would want to manually push back a memcg by changing the watermark. Ying wrote in another email that she wants to do this to make room for another job that is about to get launched. My reply to that was that you should just launch the job and let global memory pressure push back that memcg instead. So instead of lowering the watermark, you could lower the soft limit and don't do any reclaim at all until real pressure arises. You said yourself that the new feature should be called soft limit. And I think it is because it is a reimplementation of the soft limit! I am sorry that I am such a drag regarding this, please convince me so I can crawl back to my cave ;) Hannes -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx 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>