lkml.org 
[lkml]   [2004]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: Hugetlb demanding paging for -mm tree
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.067 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site