On Wed, Feb 04, 2004 at 06:00:18PM +0000, Patrick Welche wrote:
> On Wed, Feb 04, 2004 at 02:29:44PM +0000, Frank Kardel wrote:
...
> 
> Possibly:
> 
> % uname -sr && uptime && pmap 0 | wc -l
> NetBSD 1.6ZI
>  3:27PM  up 22:16, 6 users, load averages: 1.33, 1.62, 1.63
> date
>    47165
> % Wed Feb  4 16:34:17 GMT 2004
> 
> As in it took 1:07 to do the pmap.. At least that gives 2 options:
> - try compiling with NEW_BUFQ_STRATEGY
As i expected this didn't improve the situation much. 
- reboot
- ps running with about 70ms system time.
- starting to build a release - ps takes about 6 seconds system time.
  - Around 6800 entries in kernel map.
- after release build
  - ps alxww: 0.029u 27.702s 0:28.01 98.9%    0+0k 0+0io 2pf+0w -> @96 procs: ~290 ms/process!
  - pmap 0 | wc: 23017  138098 1148633

Looks like ps/pmap suffer immensely from recent changes. Also
ps/pmap seem in invoke operations that do not scale well and
seem to be related to kernel map fragmentation. 

BTW: kernel.maxvnodes is 128000.


> - try code from before 2004/01/29 12:06:02; reverting workaround for
>   PR/24039
> 
> Cheers,
> 
> Patrick
> 
Frank