On Mon, 14 Mar 2011 23:32:38 -0700, Greg Thelen wrote:

On Mon, Mar 14, 2011 at 8:10 AM, Minchan Kim [off-list ref] wrote:

quoted

On Fri, Mar 11, 2011 at 10:43:26AM -0800, Greg Thelen wrote:

quoted

Add calls into memcg dirty page accounting.  Notify memcg when pages
transition between clean, file dirty, writeback, and unstable nfs.
This allows the memory controller to maintain an accurate view of
the amount of its memory that is dirty.

Signed-off-by: Greg Thelen <redacted>
Signed-off-by: Andrea Righi <redacted>
Acked-by: KAMEZAWA Hiroyuki <redacted>
Reviewed-by: Daisuke Nishimura <redacted>

<snip>

quoted

At least in mainline, NR_WRITEBACK handling codes are following as.

1) increase

* account_page_writeback

2) decrease

 * test_clear_page_writeback
 * __nilfs_end_page_io

I think account_page_writeback name is good to add your account function into that.
The problem is decreasement. Normall we can handle decreasement in test_clear_page_writeback.
But I am not sure it's okay in __nilfs_end_page_io.
I think if __nilfs_end_page_io is right, __nilfs_end_page_io should call
mem_cgroup_dec_page_stat(page, MEMCG_NR_FILE_WRITEBACK).

What do you think about it?



--
Kind regards,
Minchan Kim

I would like to not have any special cases that avoid certain memory.
So I think your suggestion is good.
However, nilfs memcg dirty page accounting was skipped in a previous
memcg dirty limit effort due to complexity.  See 'clone_page'
reference in:
  http://lkml.indiana.edu/hypermail/linux/kernel/1003.0/02997.html

I admit that I don't follow all of the nilfs code path, but it looks
like some of the nilfs pages are allocated but not charged to memcg.
There is code in mem_cgroup_update_page_stat() to gracefully handle
pages not associated with a memcg.  So perhaps nilfs clone pages dirty
[un]charge could be attempted.  I have not succeeded in testing in
exercising these code paths in nilfs.

Sorry for this matter.  The clone_page code paths in nilfs is
exercised only when mmapped pages are written back.

I think the private page allocation used for the current clone_page
code should be altered to eliminate the root cause of these issues.
I would like to try to find some sort of alternative way.


Regards,
Ryusuke Konishi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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@kvack.org"> email@kvack.org </a>