Re: What to expect with the 2.6 VM

[Mel Gorman]

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