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/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:16 EST