On Mon, Mar 15, 2010 at 11:41 PM, Daisuke Nishimura <nishimura@xxxxxxxxxxxxxxxxx> wrote: > On Mon, 15 Mar 2010 00:26:39 +0100, Andrea Righi <arighi@xxxxxxxxxxx> wrote: >> Document cgroup dirty memory interfaces and statistics. >> >> Signed-off-by: Andrea Righi <arighi@xxxxxxxxxxx> >> --- >> Documentation/cgroups/memory.txt | 36 ++++++++++++++++++++++++++++++++++++ >> 1 files changed, 36 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt >> index 49f86f3..38ca499 100644 >> --- a/Documentation/cgroups/memory.txt >> +++ b/Documentation/cgroups/memory.txt >> @@ -310,6 +310,11 @@ cache - # of bytes of page cache memory. >> rss - # of bytes of anonymous and swap cache memory. >> pgpgin - # of pages paged in (equivalent to # of charging events). >> pgpgout - # of pages paged out (equivalent to # of uncharging events). >> +filedirty - # of pages that are waiting to get written back to the disk. >> +writeback - # of pages that are actively being written back to the disk. >> +writeback_tmp - # of pages used by FUSE for temporary writeback buffers. >> +nfs - # of NFS pages sent to the server, but not yet committed to >> + the actual storage. Should these new memory.stat counters (filedirty, etc) report byte counts rather than page counts? I am thinking that byte counters would make reporting more obvious depending on how heterogeneous page sizes are used. Byte counters would also agree with /proc/meminfo. Within the kernel we could still maintain page counts. The only change would be to the reporting routine, mem_cgroup_get_local_stat(), which would scale the page counts by PAGE_SIZE as it does for for cache,rss,etc. -- Greg -- 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/ . Don't email: <a href