RE: Hugetlb demanding paging for -mm tree

From: Seth, Rohit <rohit.seth_at_intel.com>
Date: 2004-08-11 10:28:27
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-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Tue Aug 10 20:29:44 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:29 EST