Subject: Efficiency of nfsiod
To: Neil A. Carson <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 11/09/1998 22:22:31
>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
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...