On Wed, 19 Oct 2011 18:33:09 -0700 Michal Hocko <mhocko@xxxxxxx> wrote: > Hi all, > this is a request for discussion (I hope we can touch this during memcg > meeting during the upcoming KS). I have brought this up earlier this > year before LSF (http://thread.gmane.org/gmane.linux.kernel.mm/60464). > The patch got much smaller since then due to excellent Johannes' memcg > naturalization work (http://thread.gmane.org/gmane.linux.kernel.mm/68724) > which this is based on. Yes, Johannes' work will make isolation smarter. > I realize that this will be controversial but I would like to hear > whether this is strictly no-go or whether we can go that direction (the > implementation might differ of course). > > The patch is still half baked but I guess it should be sufficient to > show what I am trying to achieve. > The basic idea is that memcgs would get a new attribute (isolated) which > would control whether that group should be considered during global > reclaim. > This means that we could achieve a certain memory isolation for > processes in the group from the rest of the system activity which has > been traditionally done by mlocking the important parts of memory. > This approach, however, has some advantages. First of all, it is a kind > of all or nothing type of approach. Either the memory is important and > mlocked or you have no guarantee that it keeps resident. > Secondly it is much more prone to OOM situation. > Let's consider a case where a memory is evictable in theory but you > would pay quite much if you have to get it back resident (pre calculated > data from database - e.g. reports). The memory wouldn't be used very > often so it would be a number one candidate to evict after some time. > We would want to have something like a clever mlock in such a case which > would evict that memory only if the cgroup itself gets under memory > pressure (e.g. peak workload). This is not hard to do if we are not > over committing the memory but things get tricky otherwise. > With the isolated memcgs we get exactly such a guarantee because we would > reclaim such a memory only from the hard limit reclaim paths or if the > soft limit reclaim if it is set up. > > Any thoughts comments? > I can only say - it can be implemented in a clean way. - maybe customers wants it. - This kinds of "mlock" can be harmful and make system admin difficult. - I'm not sure there will be a chance for security issue, DOS attack. Hmm...if the number of isolated pages can be shown in /proc/meminfo, I'll not have strong NACK. But I personally think we should make softlimit better rather than adding new interface. If this feature can be archieved when setting softlimit=UNLIMITED, it's simple. And Johannes' work will make this easy to be implemented. (total rewrite of softlimit should be required...I think.) Thanks, -Kame -- 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>