Re: [RFC][PATCH 1/3] radix priority search tree - objrmapcomplexity fix

[Andrew Morton]

Andrea Arcangeli <andrea@xxxxxxx> wrote:
>
> 
>  I'm very convinced that the alloc_pages API should be the same for all
>  archs w/o or w/ MMU, and I'm fine if we want to make the non-compound
>  retval the default (and change __GFP_NO_COMP to __GFP_COMP) in the long
>  run (to optimize all callers but hugetlbfs). For the short term
>  __GFP_NO_COMP and compound being the default is the safest (for all
>  archs).

This single patch which enables the compound page logic in
get_page()/put_page():


--- 25/include/linux/mm.h~a	2004-04-03 11:50:56.900246584 -0800
+++ 25-akpm/include/linux/mm.h	2004-04-03 11:50:59.189898504 -0800
@@ -236,7 +236,7 @@ struct page {
 
 extern void FASTCALL(__page_cache_release(struct page *));
 
-#ifdef CONFIG_HUGETLB_PAGE
+#ifndef CONFIG_HUGETLB_PAGE
 
 static inline int page_count(struct page *p)
 {


Increases a 3.5MB vmlinux by 15kB, a lot of it fastpath.  We should retain
this optimisation.

It might be better to switch over to address masking in get_user_pages()
and just dump all the compound page logic.  I don't immediately see how the
get_user_pages() caller can subsequently do put_page() against the correct
pageframe, but I assume you worked that out?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/