The patch titled
Subject: mm: fix incorrect NR_FREE_PAGES accounting (appears like memory leak)
has been removed from the -mm tree. Its filename was
mm-fix-incorrect-nr_free_pages-accounting-appears-like-memory-leak.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>
Subject: mm: fix incorrect NR_FREE_PAGES accounting (appears like memory leak)
There have been some 3.7-rc reports of vm issues, including some
kswapd bugs and, more importantly, some memory "leaks":
http://www.spinics.net/lists/linux-mm/msg46187.html
https://bugzilla.kernel.org/show_bug.cgi?id=50181
The post-3.6 commit 1fb3f8ca ("mm: compaction: capture a suitable
high-order page immediately when it is made available") took
split_free_page() and reused it for the compaction code. It does
something curious with capture_free_page() (previously known as
split_free_page()):
int capture_free_page(struct page *page, int alloc_order,
...
__mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order));
- /* Split into individual pages */
- set_page_refcounted(page);
- split_page(page, order);
+ if (alloc_order != order)
+ expand(zone, page, alloc_order, order,
+ &zone->free_area[order], migratetype);
Note that expand() puts the pages _back_ in the allocator, but it does not
bump NR_FREE_PAGES. We "return" 'alloc_order' worth of pages, but we
accounted for removing 'order' in the __mod_zone_page_state() call. For
the old split_page()-style use (order==alloc_order) the bug will not
trigger. But, when called from the compaction code where we occasionally
get a larger page out of the buddy allocator than we need, we will run in
to this.
This patch simply changes the NR_FREE_PAGES manipulation to the correct
'alloc_order' instead of 'order'.
I've been able to repeatedly trigger this in my testing environment. The
amount "leaked" very closely tracks the imbalance I see in buddy pages vs.
NR_FREE_PAGES. I have confirmed that this patch fixes the imbalance
Signed-off-by: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>
Acked-by: Mel Gorman <mgorman@xxxxxxx>
Reported-by: Milos Jakovljevic <sukijaki@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/page_alloc.c~mm-fix-incorrect-nr_free_pages-accounting-appears-like-memory-leak mm/page_alloc.c
--- a/mm/page_alloc.c~mm-fix-incorrect-nr_free_pages-accounting-appears-like-memory-leak
+++ a/mm/page_alloc.c
@@ -1405,7 +1405,7 @@ int capture_free_page(struct page *page,
mt = get_pageblock_migratetype(page);
if (unlikely(mt != MIGRATE_ISOLATE))
- __mod_zone_freepage_state(zone, -(1UL << order), mt);
+ __mod_zone_freepage_state(zone, -(1UL << alloc_order), mt);
if (alloc_order != order)
expand(zone, page, alloc_order, order,
_
Patches currently in -mm which might be from dave@xxxxxxxxxxxxxxxxxx are
memory-hotplug-update-mce_bad_pages-when-removing-the-memory.patch
memory-hotplug-update-mce_bad_pages-when-removing-the-memory-fix.patch
memory-hotplug-auto-offline-page_cgroup-when-onlining-memory-block-failed.patch
memory-hotplug-fix-nr_free_pages-mismatch.patch
memory-hotplug-mm-sparsec-clear-the-memory-to-store-struct-page.patch
memory-hotplug-allocate-zones-pcp-before-onlining-pages.patch
mm-cma-skip-watermarks-check-for-already-isolated-blocks-in-split_free_page-fix-fix.patch
drop_caches-add-some-documentation-and-info-messsge.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
