lkml.org 
[lkml]   [2004]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] VM routine fixes
David Howells <dhowells@redhat.com> wrote:
>
> Compound pages seem to be in some way tied to the TLB entry coverage sizes
> available (for hugetlb), so it's not obvious that it's permitted to have
> compound pages not of these sizes, and as I need to allocate arbitrary
> sizes...

We've considered enabling compound pages permanently. We thought sparc64
might want that, and it simplifies coverage testing. But the
conditionality has been left in for now as a microoptimisation.

> If I am correct about this, then the !MMU problem would still exist - just
> with adjacent sets of compound pages rather than adjacent sets of pages.

Why _does_ !CONFIG_MMU futz around with page counts in such weird ways
anyway? Why does it have requirements for higher-order pages which differ
from !CONFIG_MMU?

If someone could explain the reasoning behind the current code, and the FRV
enhancements then perhaps we could work something out.

> Compound pages might be nice, but they're overkill.

I don't expect they have significant performance overhead, because they'll
only add cycles for higher-order pages. They're rare, and are already
rather inefficient.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:3.305 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site