On Sun, 13 Jan 2008, Nick Piggin wrote:
>
> mm: introduce pte_special pte bit
What's the point of this?
> 23 files changed, 147 insertions(+), 37 deletions(-)
That's lots of new (ugly) code, and two totally different paths, that
aren't even cleanly abstracted, so now there's two separate things that
are just arbitrarily selected by an #ifdef.
You seem to claim that this is a performance issue, with vm_normal_page()
eating up to 5% of time on some loads, but it would appear that the main
thing you did that will speed up vm_normal_page() is the fact that you
replaced the current
if (unlikely(!pfn_valid(pfn))) {
print_bad_pte(vma, pte, addr);
return NULL;
}
with a
VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
which is basically compiled away in the normal case.
>From what I can tell, your vm_normal_page() is no less expensive than the
current one is: the cost is always going to be that multiply by the size
of the "struct page" implicit in
pte_page(pte)
(which in the current one is just written out as
pfn = pte_pfn(pte)
pfn_page(pfn)
rather than hidden in a macro).
Does the code generation really change that radically that this makes any
real difference?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
