On Tue, 23 Feb 2010 15:26:34 +0100 Andrea Arcangeli <aarcange@xxxxxxxxxx> wrote: > On Tue, Feb 23, 2010 at 04:58:07PM +0900, KAMEZAWA Hiroyuki wrote: > > I'm not sure but....where this *hpage is chareged to proper memcg ? > > I think it's good to charge this newpage in the top of this function. > > (And cancel it at failure, of course.) > > That is just a temporary page owned by khugepaged, not owned by any > memcg user. Who should I account it against? If allocation fails > khugepaged just waits alloc_sleep_msec and tries again later. > I can't track all your code, too complex. What I can see via this patch 36/36 is - all mapped pages are uncharged at page_remove_rmap(), - huge page (new_page) is not charged. > When the allocated page is actually used to collapse an hugepage, an > amount of memory equal to the size of the hpage is released. In turn > khugepaged changes nothing in the memcg accounting. That's wrong. We cannot assume all mapped pages are belongs to the same memcg. You should think - all mapped pages are uncharged when page_remove_rmap() is called in __collapse_huge_page() from unknown memcg. - You have to charge a new hugepage when it's mapped to mm's memcg. Then, silent account migration occurs. I think it's small problem but should be documented somewhere. Thanks, -Kame -- 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>