chuq@chuq.com wrote:

> 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.

BTW, currently buffer cache size is limited in 3MB by buf_setvalimit(),
but on the old "traditional buffer cache" system, bufpages was
limited with only (128 * PAGE_SIZE), i.e. 512KB on sun4c.
If buffer cache allocation could be fragmented, should we also
reduce this?

>   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
 :
> 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.

Yes, it is, I just noticed it on testing a yamt-splraisespl kernel.
(IIRC last time I tried build.sh on my SS1+ was about a year ago)
Note, new ld(1) would consume much more memory unless --no-keep-memory
option is specified.

Anyway, I'll try to reduce ubc_nwins and an arg of buf_setvalimit
and see how it goes.
---
Izumi Tsutsui