The patch titled
Subject: slub: use free_page() instead of put_page() for freeing kmalloc() allocation
has been removed from the -mm tree. Its filename was
slub-use-free_page-instead-of-put_page-for-freeing-kmalloc-allocation.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Glauber Costa <glommer@xxxxxxxxxxxxx>
Subject: slub: use free_page() instead of put_page() for freeing kmalloc() allocation
When freeing objects, the slub allocator will most of the time freeing
empty pages by calling __free_pages(). But high-order kmalloc() will be
diposed by means of put_page() instead. It makes no sense to call
put_page() against kernel pages that are provided by the object
allocators, so we shouldn't be doing this ourselves. Aside from the
consistency change, we don't change the flow too much. put_page()'s would
call its dtor function, which is __free_pages. We also already do all of
the Compound page tests ourselves, and the Mlock test we lose don't really
matter.
Signed-off-by: Glauber Costa <glommer@xxxxxxxxxxxxx>
Acked-by: Christoph Lameter <cl@xxxxxxxxx>
Cc: David Rientjes <rientjes@xxxxxxxxxx>
Cc: Pekka Enberg <penberg@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/slub.c~slub-use-free_page-instead-of-put_page-for-freeing-kmalloc-allocation mm/slub.c
--- a/mm/slub.c~slub-use-free_page-instead-of-put_page-for-freeing-kmalloc-allocation
+++ a/mm/slub.c
@@ -3477,7 +3477,7 @@ void kfree(const void *x)
if (unlikely(!PageSlab(page))) {
BUG_ON(!PageCompound(page));
kmemleak_free(x);
- put_page(page);
+ __free_pages(page, compound_order(page));
return;
}
slab_free(page->slab, page, object, _RET_IP_);
_
Patches currently in -mm which might be from glommer@xxxxxxxxxxxxx are
linux-next.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
