Messages in this thread | | | Subject | RE: Hugetlb demanding paging for -mm tree | Date | Tue, 10 Aug 2004 17:28:27 -0700 | From | "Seth, Rohit" <> |
| |
William Lee Irwin III <mailto:wli@holomorphy.com> wrote on Tuesday, August 10, 2004 1:56 AM:
> William Lee Irwin III <> wrote on Monday, August 09, 2004 11:59 AM: >>> As things stand in mainline, it's not an obvious issue. Ken appears >>> to be calling it for hugetlb in the ZFOD fault handling patches, >>> which have the issue that it may behave badly in several respects >>> when acting on large pages. The cache coherency bits in >>> update_mmu_fault() are necessary in general, but mainline omits >>> them. It should only result in intermittent failures on machines >>> with sufficiently incoherent caches. > > On Tue, Aug 10, 2004 at 01:52:02AM -0700, Seth, Rohit wrote: >> Will the flush_dcache_page for hugepages even on incoherent caches be >> not enough. And that flush_dcache_page should be done in >> alloc_hugepage after clearing the page(or change the clear_highpage >> to clear_user_high_page). > > Could you rephrase that? I'm having trouble figuring out what you > meant. > > > -- wli
I was thinking that we only need to worry about the d-cache coherency at the time of hugepage fault. But that is not a safe assumption. You are right that we will need update_mmu_cache in the hugetlb page fault path. Though I'm wondering if we can hide this update_mmu_cache fucntionality behind the arch specific set_huge_pte function in the demand paging patch for hugepage. If so then we may not need to make any changes in the existing update_mmu_cache API.
Thanks, rohit - 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/
| |