lkml.org 
[lkml]   [2004]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 14:07    [W:0.024 / U:60.424 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site