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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html