[ Chuck- Matt Green dobbed you in as the current Mr Sparc64 Pmap Guy :) ]

mrg@eterna.com.au wrote:

> 	top running on a 32 bit sparc64 machine uses huge amounts
> 	of CPU time.  from the top display, of a normal "top" with
> 	no arguments (ie, 2 second updates):
> 
> 	  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
> 	 8684 mrg       50    0   320K 1240K CPU        0:15 33.60% 29.88% top
> 
> 	my machine is also seems to pause a lot during this time.

Output from gprof shows we're spending a lot of time in
pmap_count_res():

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  us/call  us/call  name
 58.33      0.07     0.07       20  3500.00  3500.00  pmap_count_res
 16.67      0.09     0.02                             shl
  8.33      0.10     0.01       62   161.29   161.29  pmap_remove
  8.33      0.11     0.01       56   178.57   178.57  pmap_zero_page
  8.33      0.12     0.01       49   204.08   204.08  idle

...

index % time    self  children    called     name
-----------------------------------------------  
                0.00    0.07      20/20          sysctl_doeproc [7]
[4]     58.3    0.00    0.07      20         fill_kproc2 [4]
                0.07    0.00      20/20          pmap_count_res [5]
                0.00    0.00      60/60          strncpy [165]
                0.00    0.00      20/60          memset [163]
                0.00    0.00      20/600         bcopy [97]
                0.00    0.00      20/600         memcpy [98]
-----------------------------------------------
                0.07    0.00      20/20          fill_kproc2 [4]
[5]     58.3    0.07    0.00      20         pmap_count_res [5]
-----------------------------------------------


This is from fill_kproc2():

	...
	ep->e_vm.vm_rssize = vm_resident_count(vm);
	...

Most (all?) other pmaps keep the pm_stats counters up-to-date and simply
return that counter instead of calculating them on the fly.  Should the
sparc64 pmap do this too?

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/