Hi Mel, I'm chasing an apparent memory leak introduced post-3.6. The interesting thing is that it appears that the pages are in the allocator, but not being accounted for: http://www.spinics.net/lists/linux-mm/msg46187.html https://bugzilla.kernel.org/show_bug.cgi?id=50181 I started auditing anything that might be messing with NR_FREE_PAGES, and came across commit 1fb3f8ca. 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'. I _think_ the correct fix is to just: - __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order)); + __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << alloc_order)); I'm trying to confirm the theory my making this happen a bit more often, but I'd appreciate a second pair of eyes on the code in case I'm reading it wrong. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>