On Sun, Oct 15, 2006 at 10:35:04AM -0700, Chuck Silvers wrote:
> it's not really clear that the UBC mappings are the problem.
> on sun4c machines, UBC mappings are limited to using 4MB (out of
> a total of 64MB that can be mapped simultaneously by the hardware).

er, I was looking at a sparc2, the lower-end sun4cs can only map half that.
so we should reduce the UBC space some, setting ubc_nwins to 128 in this case
would probably be good.  I don't think we should eliminate caching of these
mappings entirely, that would cause other cases to become slower.

also, looking back at the original mail, we can see that it's the gcc process
that's really using most of the PMEGs:

  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
 3974 root      59    0    10M   19M RUN       20:20 84.81% 84.81% cc1

I assume that the kernel being used here was a minimal one, with all
unnecessary drivers and options being turned off?  that can save 2.5 MB
of wired kernel memory vs. a GENERIC kernel.

was this the first time anyone looked at the performance of build.sh
on sun4c since gcc was upgraded to 4.x?  I would bet the new gcc is
using more memory than the previous version did.

-Chuck