Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked

From: azurIt
Date: Thu Dec 06 2012 - 05:12:40 EST

>Dohh. The very same stack mem_cgroup_newpage_charge called from the page
>fault. The heavy inlining is not particularly helping here... So there
>must be some other THP charge leaking out.
>[/me is diving into the code again]
>* do_huge_pmd_anonymous_page falls back to handle_pte_fault
>* do_huge_pmd_wp_page_fallback falls back to simple pages so it doesn't
> charge the huge page
>* do_huge_pmd_wp_page splits the huge page and retries with fallback to
> handle_pte_fault
>* collapse_huge_page is not called in the page fault path
>* do_wp_page, do_anonymous_page and __do_fault operate on a single page
> so the memcg charging cannot return ENOMEM
>There are no other callers AFAICS so I am getting clueless. Maybe more
>debugging will tell us something (the inlining has been reduced for thp
>paths which can reduce performance in thp page fault heavy workloads but
>this will give us better traces - I hope).

Should i apply all patches togather? (fix for this bug, more log messages, backported fix from 3.5 and this new one)

>Anyway do you see the same problem if transparent huge pages are
>echo never > /sys/kernel/mm/transparent_hugepage/enabled)

# cat /sys/kernel/mm/transparent_hugepage/enabled
cat: /sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at