[PATCH] mark_page_accessed() in do_swap_page() move latter than memcg charge

[KOSAKI Motohiro]

sorry for late responce.

> > In this case we've hit a case where the page is valid and the pc is
> > not. This does fix the problem, but won't this impact us getting
> > correct reclaim stats and thus indirectly impact the working of
> > pressure?
> > 
>  - If retruns NULL, only global LRU's status is updated. 
> 
> Because this page is not belongs to any memcg, we cannot update
> any counters. But yes, your point is a concern.
> 
> Maybe moving acitvate_page() to
> ==
> do_swap_page()
> {
>     
> - activate_page()
>    mem_cgroup_try_charge()..
>    ....
>    mem_cgroup_commit_charge()....
>    ....
> +  activate_page()   
> }
> ==
> is necessary. How do you think, kosaki ?


OK. it makes sense. and my test found no bug.

==

mark_page_accessed() update reclaim_stat statics.
but currently, memcg charge is called after mark_page_accessed().

then, mark_page_accessed() don't update memcg statics correctly.

fixing here.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
Cc: Daisuke Nishimura <nishimura@xxxxxxxxxxxxxxxxx>
Cc: Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx>

---
 mm/memory.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/mm/memory.c
===================================================================
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2426,8 +2426,6 @@ static int do_swap_page(struct mm_struct
 		count_vm_event(PGMAJFAULT);
 	}
 
-	mark_page_accessed(page);
-
 	lock_page(page);
 	delayacct_clear_flag(DELAYACCT_PF_SWAPIN);
 
@@ -2480,6 +2478,8 @@ static int do_swap_page(struct mm_struct
 		try_to_free_swap(page);
 	unlock_page(page);
 
+	mark_page_accessed(page);
+
 	if (write_access) {
 		ret |= do_wp_page(mm, vma, address, page_table, pmd, ptl, pte);
 		if (ret & VM_FAULT_ERROR)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/