[PATCH v6 4/9] memcg: add kernel calls for memcg dirty page stats

[Ryusuke Konishi]

On Mon, 14 Mar 2011 23:32:38 -0700, Greg Thelen wrote:
> On Mon, Mar 14, 2011 at 8:10 AM, Minchan Kim <minchan.kim at gmail.com> wrote:
>> On Fri, Mar 11, 2011 at 10:43:26AM -0800, Greg Thelen wrote:
>>> 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 <gthelen at google.com>
>>> Signed-off-by: Andrea Righi <arighi at develer.com>
>>> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu at jp.fujitsu.com>
>>> Reviewed-by: Daisuke Nishimura <nishimura at mxp.nes.nec.co.jp>
<snip>
>>
>> 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