lkml.org 
[lkml]   [2003]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: What to expect with the 2.6 VM
    On Tue, 1 Jul 2003, Andrea Arcangeli wrote:

    > > Non-Linear Populating of Virtual Areas
    > > ======================================
    > >
    > and it was used to break truncate, furthmore the API doesn't look good
    > to me, the vma should have a special VM_NONLINEAR created with a
    > MAP_NONLINEAR so the vm will skip it enterely and it should be possible
    > to put multiple files in the same vma IMHO.

    OK, I think I absorbed most of this and read through most of the old
    threads on the subject that I could find. It is very difficult to express
    all the viewpoints in any type of concise manner so I'm settling for
    getting about 70% of it.

    The discussions on what API to use instead are all over the place and I
    got lost in a twisty maze of emails, all similar. Below is the summary of
    what I found that could be made into something coherent.

    --Begin Extract--
    Whether this feature should remain is still being argued but it is likely
    to remain until an acceptable alternative is implemented. The main
    benefits only apply to applications such as database servers or
    virtualising applications such as emulators. There is a small number of
    reasons why it was introduced.

    The first is space requirements for large numbers of mappings. For every
    mapped region a process needs, a VMA has to be allocated to it which
    becomes a considerable space commitment when a process needs a large
    number of mappings. At worst case, there will be one VMA for every
    file-backed page mapped by the process.

    The second reason is avoiding the poor linear search algorithm used by
    get_unmapped_area() when looking for a large free virtual area. With a
    large number of mappings, this search is very expensive. It has been
    proposed to alter the function to perform a tree based search. This could
    be a tree of free areas ordered by size for example but none has yet been
    implemented. In the meantime, non-linear mappings are being used to bypass
    the VM.

    The third reason is related to frequent page faults associated with linear
    mappings. A non-linear mapping is able to prefault in all pages that are
    required by the mapping as it is presumed they will be needed very soon.
    To some extent, this can be addressed by specifying the MAP_POPULATE when
    calling mmap() for a normal mapping.

    This feature has a very serious drawback. The system calls truncate() and
    mincore() are broken with respect to non-linear mappings. Both calls
    depend on vm_area_struct>vm_pgoff, which is the offset within
    the mapped file, but the field is meaningless within a non-linear mapping.
    This means that truncated files will still have mapped pages that no
    longer have a physical backing. A number of possible solutions, such as
    allowing the pages to exist but be anonymous and private to the process,
    have been suggested but none implemented.

    --End Extract--

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