>   Now, pages eligible for page-out do not normally map to kernel addresses,
>   unless it's double-mapped user page doing physio() or something like that.

>i wonder what UVM will bring to this problem.  :-)


object and anonymous pages are allowed to be in the kernel map.
this is currently used for doing "struct uio" I/O to a vm_map:

        int uvm_io __P((vm_map_t, struct uio *));

that is used by ptrace and procfs to safely read/write to a map.

basically, uvm_io extracts vm_map_entry's from the target map, installs
them in the kernel_map, then does a bcopy (possibly causing a fault),
and then removes the mappings from the kernel map.    if the uio is
for a large sized request, then uvm_io will break it up into smaller
chunks (since there is only so much KVM to go around).

[note that the old trick of doing a vm_fault() and then a pmap_extract()
 isn't good enough if more than one thread is sharing the vm_map...
 another thread could destroy the mapping established by vm_fault()
 before the pmap_extract() is done...]


if a page is paged out during there is no problem: the page will
be pmap_page_protect(pg, VM_PROT_NONE) before being freed ... this
will cause the uvm_io's bcopy to refault in the page when it is
next referenced.



for pages which are "loaned" from objects to the kernel (e.g. to
the mbuf system): these pages are wired and will not get paged out
by the page daemon.   it is still possible for them to get flushed
though (e.g. with msync).   in this case the "loaned" pages are
donated to the kernel and the object drops ownership of them.
when the kernel is done with the pages, it will note that the pages
are orphaned and free them.   [this provides a copy-on-write like
semantics to page loaning...]


chuck