Messages in this thread |  | | | Date | Fri, 22 Oct 2004 08:42:19 -0700 | | From | William Lee Irwin III <> | | Subject | Re: Hugepages demand paging V1 [2/4]: set_huge_pte() arch updates |
| |
On Fri, 22 Oct 2004, William Lee Irwin III wrote: >> What's described above is not what the patch implements. The patch is >> calling update_mmu_cache() in a loop on all the virtual base pages of a >> virtual hugepage, which won't help at all, as it doesn't understand how >> to find the hugepages regardless of virtual address. AFAICT code to >> actually do the equivalent of update_mmu_cache() on hugepages most >> likely involves privileged instructions and perhaps digging around some >> cpu-specific data structures (e.g. the natively architected pagetables >> bearing no resemblance to Linux') for almost every non-x86 architecture.
On Fri, Oct 22, 2004 at 08:32:34AM -0700, Christoph Lameter wrote: > The looping is architecture specific. But you are right for the > architectures where I simply did the loop that is wrong. The address given > needs to be correctly calculated which it is not. > Again this is arch specific stuff and can be done as needed for any > architecture. There is no intend to generalize this.
The "model", as it were, for pagetable updats, is a 3-stage model: (1) prepare (2) update (3) commit
update_mmu_cache() is stage (3). Linux' software pagetable modifications are step (2). Generally, architectures are trying to fold stages (2) and (3) together in set_huge_pte(), so update_mmu_cache() is not so much of an issue for them (and it's actually incorrect to do this multiple times or without the architectures' awareness of hugepages in update_mmu_cache() and so on). To completely regularize the hugetlb case, merely move the commitment to cpu-native structures or other TLB insertion done within set_huge_pte() to a new case in update_mmu_cache() for large pages.
What is in fact far more pressing is flush_dcache_page(), without a correct implementation of which for hugetlb, user-visible data corruption follows.
-- wli - 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/
|  |