On Tue, Mar 15, 2011 at 7:01 AM, Mike Heffner <mike@xxxxxxxxxxx> wrote: > On 03/11/2011 01:43 PM, Greg Thelen wrote: >> >> Add cgroupfs interface to memcg dirty page limits: >> Direct write-out is controlled with: >> - memory.dirty_ratio >> - memory.dirty_limit_in_bytes >> >> Background write-out is controlled with: >> - memory.dirty_background_ratio >> - memory.dirty_background_limit_bytes > > > What's the overlap, if any, with the current memory limits controlled by > `memory.limit_in_bytes` and the above `memory.dirty_limit_in_bytes`? If I > want to fairly balance memory between two cgroups be one a dirty page > antagonist (dd) and the other an anonymous page (memcache), do I just set > `memory.limit_in_bytes`? Does this patch simply provide a more granular > level of control of the dirty limits? > > > Thanks, > > Mike > The per memcg dirty ratios are more about controlling how memory within a cgroup is used. If you isolate two processes in different memcg, then the memcg dirty ratios will neither help nor hurt isolation between cgroups. The per memcg dirty limits are more focused on providing some form of better behavior when multiple processes share a single memcg. Running an antagonist (dd) in the same cgroup as a read-mostly workload would benefit because the antagonist dirty memory usage should be capped at the memcg's dirty memory usage. So any clean page allocation requests by the read-mostly workload should be faster (and less likely to OOM) because there will be more clean pages available within the memcg. -- 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