Re: objrmap and vmtruncate

["Martin J. Bligh" <mbligh@aracnet.com>]

>> The only issues with objrmap seems to be mremap, which Hugh
>> seems to have taken care of, and the case of a large number
>> of processes mapping different parts of the same file multiple
>> times (1000 processes mapping each 1000 parts of the same file),
>> which would grow the complexity of the VMA search from linear
>> to quadratical.
>> That last case is also fixable, though, probably best done using
>> k-d trees.
>> Except for nonlinear VMAs I don't think there are any big obstacles
>> left that would keep us from switching to object rmap.
> 
> The k-d trees only solve the "external" interference case, that is,
> it thins the search space by eliminating vma's the page must
> necessarily be outside of.
> 
> They don't solve the "internal" interference case, where the page does
> fall into all of the vma's, but only a few out of those have actually
> faulted the page into the pagetables. This is likely only "fixable" by
> pointwise methods, which seem to come with notable maintenance expense.

I don't think we have an app that has 1000 processes mapping the whole
file 1000 times per process. If we do, shooting the author seems like 
the best course of action to me.

M.