On Sun, May 8, 2011 at 5:21 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > On Fri, 6 May 2011 16:22:57 +0200 > Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > >> 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. >> > > Considering the whole system, I never think this watermark can be a performance > help. This consumes the same amount of cpu as a memory freeing thread uses. > In realistic situaion, in busy memcy, several threads hits limit at the same > time and a help by a thread will not be much help. > >> 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. >> > > For keeping free memory, when the system is not busy. > >> Ying wrote in another email that she wants to do this to make room fro, >> 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! >> > > Soft limit works only when the system is in memory shortage. It means the > system need to use cpu for memory reclaim when the system is very busy. > This works always an admin wants. This difference will affects page allocation > latency and execution time of application. In some customer, when he wants to > start up an application in 1 sec, it must be in 1 sec. As you know, kswapd's > memory reclaim itself is too slow against rapid big allocation or burst of > network packet allocation and direct reclaim runs always. Then, it's not > avoidable to reclaim/scan memory when the system is busy. This feature allows > admins to schedule memory reclaim when the systen is calm. It's like control of > scheduling GC. Agree on this. For the configurable per-memcg wmarks, one of the difference from adjusting soft_limit since we would like to trigger the per-memcg bg reclaim before the whole system under memory pressure. The concept of soft_limit is quite different from the wmarks, where the first one can be used to over-committing the system efficiently which has nothing to do with per-memcg background reclaim. --Ying --Ying > > IIRC, there was a trial to free memory when idle() runs....but it doesn't meet > current system requirement as idle() should be idle. What I think is a feature > like a that with a help of memcg. > > Thanks, > -Kame > > -- 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