On Wed, 19 Jan 2011, KAMEZAWA Hiroyuki wrote: > I know. > > THIS PATCH's min_free_kbytes is not the same to ZONE's one. It's just a > trigger. This patch's one is not used to limit charge() or for handling > gfp_mask. > (We can assume it's always GFP_HIGHUSER_MOVABLE or GFP_USER in some cases.) > > So, I wrote the name of 'min_free_kbytes' in _this_ patch is a source of > confusion. I don't recommend to use such name in _this_ patch. > Agree with respect to memcg min_free_kbytes. I think it would be preferrable, however, to have a single tunable for which oom killed tasks may access a privileged pool of memory to avoid the aforementioned DoS and base all other watermarks off that value just like it happens for the global case. Your point about throttling cpu for background reclaim is also a good one: I think we should be able to control the aggressiveness of memcg background reclaim with an additional property of memcg where a child memcg cannot be more aggressive than a parent, but I think the watermark should be internal to the subsystem itself and, perhaps, based on the user tunable that determines how much memory is accessible by only oom killed tasks. -- 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 policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>