> More info:
> 
> After configuring kernels which were IDENTICAL except for procfs,
> the 'size' output from the kernel showed:
> 
> 819168  63952   78560   961680  eac90   netbsd		# no procfs
> 819168  64832   78584   962584  eb018   /netbsd		# procfs
> 
> And on disk:
> 
> -rwxr-xr-x  1 root  bin  958261 Jan 12 19:05 netbsd	# no procfs
> -rwxr-xr-x  1 root  bin  960266 Jan 12 18:01 /netbsd	# procfs
> 
> The difference in core appears to be 0+880+32; the difference
> on disk appears to be 2005 bytes.

I don't believe you.  What architecture are you talking about?

on the i386, various procfs files size to:

12 [sun-lamp] GENERIC % size procfs_*
text    data    bss     dec     hex
904     312     0       1216    4c0     procfs_ctl.o
232     0       0       232     e8      procfs_fpregs.o
564     0       0       564     234     procfs_mem.o
60      0       0       60      3c      procfs_note.o
228     0       0       228     e4      procfs_regs.o
924     0       0       924     39c     procfs_status.o
964     0       8       972     3cc     procfs_subr.o
488     52      0       540     21c     procfs_vfsops.o
3076    500     0       3576    df8     procfs_vnops.o
13 [sun-lamp] GENERIC % size ../SUN_LAMP/procfs_*
text    data    bss     dec     hex
232     0       0       232     e8      ../SUN_LAMP/procfs_fpregs.o
564     0       0       564     234     ../SUN_LAMP/procfs_mem.o
228     0       0       228     e4      ../SUN_LAMP/procfs_regs.o

the latter set are the 'standard' ones that are used by ptrace (which
in a perfect world would live elsewhere and be named differently, but
there's history there).

on a different architecture (sparc?) the numbers will be different
(and on sparc, i'd expect them to be larger).


Don't forget that, since kernel text is typically rounded to the page
size, extra space in the kernel used by the addition of procfs may be
'hidden' because it was previously wasted...  but you're then that
much closer to using another page...