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

Andrew Morton
2004-04-03T20:02:27Z

Andrea Arcangeli <andrea@suse.de> 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?