lkml.org 
[lkml]   [2003]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc)
    From
    Date
    On Sat, 2003-08-23 at 17:53, David S. Miller wrote:
    > BTW, what gains to you really get from this optimization?
    >
    > How often do writes happen to files while private mappings
    > to it exist? :-) This is one of the reasons I think this
    > discussion is a bit silly.
    >
    > What specific cases does your optimization help, and how common is it?
    > Show us some numbers.

    Not having to flush the private mappings is a huge optimisation. Our
    current flush_dcache_page implementation allows us only to flush a
    single page and get all the aliased caches updated because we carefully
    align MAP_SHARED areas (by supplying our own arch_get_unmapped_area()).

    However, the alignment constraint is 4MB to get this property of the
    virtually aliased caches, so we can't afford to align all mappings like
    this (for our 32 bit userspace, anyway).

    If we were to have to flush the private i_mmap list, we'd have to do a
    page flush for *every* entry in the list (that's 256 instructions per
    page at a cache width of 16 bytes). This would be a horrific overhead.

    using the VM_MAYSHARE to carry the read only shared mapping semantics
    indication still allows us to align correctly, but the only additional
    overhead we incur is to walk the i_mmap list to find VM_MAYSHARE
    mappings as well as i_mmap_shared. Since we can key of VM_MAYSHARE to
    do the alignment, we still only need flush the first one we come to.

    This all works as long as we can agree there are no pathological mmap
    cases that force us to flush *all* the i_mmap mappings...which is what I
    think the discussion has come down to.

    James


    -
    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 13:48    [W:0.022 / U:60.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site