The patch titled
Subject: memcg: ignore partial THP when moving task
has been added to the -mm tree. Its filename is
mm-rework-mapcount-accounting-to-enable-4k-mapping-of-thps-fix-5.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-rework-mapcount-accounting-to-enable-4k-mapping-of-thps-fix-5.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-rework-mapcount-accounting-to-enable-4k-mapping-of-thps-fix-5.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Michal Hocko <mhocko@xxxxxxxx>
Subject: memcg: ignore partial THP when moving task
After "mm: rework mapcount accounting to enable 4k mapping of THPs" it is
possible to have a partial THP accessible via ptes. Memcg task migration
code is not prepared for this situation and uncharges the tail page from
the original memcg while the original THP is still charged via the head
page which is not mapped to the moved task. The page counter of the
origin memcg will underflow when the whole THP is uncharged later on and
lead to: WARNING: CPU: 0 PID: 1340 at mm/page_counter.c:26
page_counter_cancel+0x34/0x40() reported by Minchan Kim.
This patch prevents from the underflow by skipping any partial THP pages
in mem_cgroup_move_charge_pte_range. PageTransCompound is checked when we
do pte walk. This means that a process might leave a partial THP behind
in the original memcg if there is no other process mapping it via pmd but
this is considered acceptable because it shouldn't happen often and this
is not considered a memory leak because the original THP is still
accessible and reclaimable. Moreover the task migration has always been
racy and never guaranteed to move all pages.
Reported-by: Minchan Kim <minchan@xxxxxxxxxx>
Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx>
Signed-off-by: Michal Hocko <mhocko@xxxxxxxx>
Cc: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/memcontrol.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN mm/memcontrol.c~mm-rework-mapcount-accounting-to-enable-4k-mapping-of-thps-fix-5 mm/memcontrol.c
--- a/mm/memcontrol.c~mm-rework-mapcount-accounting-to-enable-4k-mapping-of-thps-fix-5
+++ a/mm/memcontrol.c
@@ -4864,6 +4864,14 @@ retry:
switch (get_mctgt_type(vma, addr, ptent, &target)) {
case MC_TARGET_PAGE:
page = target.page;
+ /*
+ * We can have a part of the split pmd here. Moving it
+ * can be done but it would be too convoluted so simply
+ * ignore such a partial THP and keep it in original
+ * memcg. There should be somebody mapping the head.
+ */
+ if (PageCompound(page))
+ goto put;
if (isolate_lru_page(page))
goto put;
if (!mem_cgroup_move_account(page, false,
_
Patches currently in -mm which might be from mhocko@xxxxxxxx are
mm-vmstat-allow-wq-concurrency-to-discover-memory-reclaim-doesnt-make-any-progress.patch
mm-get-rid-of-__alloc_pages_high_priority.patch
mm-do-not-loop-over-alloc_no_watermarks-without-triggering-reclaim.patch
mm-vmscan-consider-isolated-pages-in-zone_reclaimable_pages.patch
mm-allow-gfp_iofs-for-page_cache_read-page-cache-allocation.patch
mm-oom-give-__gfp_nofail-allocations-access-to-memory-reserves.patch
mm-rework-mapcount-accounting-to-enable-4k-mapping-of-thps-fix-5.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
