In message <200104112300.RAA10119@forge.BSDI.COM>Chris Torek writes
[..]

>You can always *convert* it, the question is at what cost.  (Any
>virtual address is uniquely identified by the <v.a.space, v.a.value>
>pair, where the vaspace can be identified by its proc or vmspace or
>whatever you like.)
>
>One of the kernel optimizations I never got around to, which should
>help speed up context switching, is the "lazy context switch" in
>which user-space address accesses, including those done in uiomove(),
>start out with:
>
>    if (current user space != target user space)
>	vm_system.switch_user_context(target user space);
>    ... do the usual job ...

chris,

I think several of the netbsd portmasters have already done this
optimization, albeit inside the machine-dependent layer. That means a
deeper call-graph, but elides the identical set of user-VM-context switches.

IIRC, it's come up with Sun MMUs (pmegs), the ARM cpus where a
user-vm-switch requires an (i-)cache flush, and machines with hardware
ASIDs (to limit TLB flushes when there are more active procesess than
ASIDs).

Then again, i could be forgetting some crucial detail, its been awhile.

>If the code to "switch user context" handled an arbitrary user space,
>the above uiomove() would work even for processes other than the one
>you intend to return to next / are running in the kernel "on behalf of".

Hm. that could also save i- cache flushes on split-I/D but non
-mutally-consistent caches (arm, mips, others?)  at least where the
target region of the uiomove is mmap'ed as VM_READ/WRITE but not
execute.  i wonder if the test for that costs more than the gain?
OTOH, I once used a machine where the MMU had separate i-fetch and
data-fetch bits, and far too much code did mmap() with PROT_READ
when it really needed PROT_EXECUTE (or both).

Once again, time, details...