On Mon, 14 Oct 2002, William Lee Irwin III wrote:

quoted

well, i dont agree with vectorizing everything, unless it's some really
lightweight thing and/or the operation is somehow naturally vectorized.  
(block and network IO, etc.)

I would say it makes sense for its intended purpose, as large volumes of
pages are expected to be remapped this way.

volume alone does not necessiate a vectored API - everything depends on
whether the volume comes in chunks, ie. is predictable. For things like a
LRU DB-cache the order of new cache entries are largely unpredictable.  
Even if predictable then they are mostly continuous in the file space, ie.
properly vectorized by the API already. There might be cases where there
are bulk mappings, but the common case i'm quite sure isnt. Just like we
dont have bulk mmap() support either. But, if it really turns out to be a
problem then a bulk API can be added later on, which would just build upon
the existing syscall.

The VM_RANDOM flag was a safety net I believed to be beneficial, in part
because userspace would be limited in how it can utilize the remapping
facility without guarantees that mappings are not implicitly established
in ways it does not expect.

if this is really an issue then we could force vma->vm_page_prot to
PROT_NONE within remap_file_pages(), so at least all subsequent faults
will be PROT_NONE and the user would have to explicitly re-mprotect() the
vma again to change this.

quoted

how would you do this actually, without other restrictions?

It would be easy to keep the VM_RANDOM flag for truly random vma's, and
check for file offsets matching in the prefault path for others.

there is no 'VM_RANDOM' flag right now - because *any* shared mapping can
be used with remap_file_pages(). I think forcing the default protection to
PROT_NONE should solve the problem - this is the most logical thing to do
in the MAP_LOCKED case as well.

A nonblocking filemap_populate() may partially populate a virtual
address range and the user may later fault in pages not file offset
contiguous in the prefaulted region as opposed to discovering them as
not present. For the MAP_LOCKED | PROT_NONE scenario this would apply
only with a nonblocking prefault on a MAP_LOCKED vma, where the caller
would find stale mappings where the prefault operation failed, and even
if the nonblocking path invalidated the pte's one would still return to
faulting in of the wrong pages. This is a safety question limiting the
usefulness of nonblocking prefaults on scatter gather vma's to
userspace.

this too is handled by changing the default protection to PROT_NONE. A
user would have to deliberately change the protection to get rid of this
safety net - at which point no harm will be done, the user will get what
he asked for.

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/