>On VAC architectures it may be beneficial, during context switches, to
    ^^^^ easily misread as "vax", one  arcitecture where
         ldpctxt/svpctxt means you just cant do this :)

>check the vmspaces of the from/to processes in order to check if they
>both exist within the kernel. If this is the case, it is possible to
>switch faster because the mappings don't need to be changed. Under,
>like, a heavy pagedaemon, this could make a difference.


>Now picture an NFS system running a few nfsiod's. Would it be possible
>to implement them as kernel processes for the same reason? Just a
>thought.

Yes, it should.

It was known win for SunOS on the sun3 and sun4/sun4c with the Sun
"pmeg" mmu. Sun shipped this around, oh, SunOS 4.1; it made a
noticeable difference.  I thought NetBSD already did this on some
ports, at least for inkernel threads...  but looking at
sys/nfs/nfs_syscalls.c, it seems we dont.    Yow. 

Making nfsiod's kernel-only processes (throwing away the vmspace, and
grabbing a new one if/when they ever exit) would make a really nice
project.  It'd mean expanding the pmap module to do the throwing away
and reallocating, though (unless pmap_new has it).  But for a first
pass, they could always be no-ops for most arches.

Someone -- gwr(?) suggested something very similar for mips: having a
designated "empty" userspace pmap, and sharing that single pmap across
all kernel-mode-only processes. (we dont do it fully yet because it'
break our current kstack over/underflow red-zoning.)


The trick should also be a win on, say, arm32 cpus with a
virtually-indexed icache and no ASID hardware.  You usually have to
flush the entire Icache on every context-switch, but for kernel-only
proceses.  you could elide that.  You'd lose some of the HW checks
against wild kernel jumps into userspace code: if the target userspace
address had footprint in the i-cache, the hw wouldnt trap it
(afaik). normal testing should catch gross bugs like that.

I mentioned gwr's suggestion in an email discussion with Mark
Brinicombe somtime early this year. Now that we use a kernel-only
reaper pseudo-process to clean up kernel stacks, if the netbsd arm32
code doesnt already have machinery to do this, there's probably a good
reason not to...