NetBSD/vax performance (Was: /etc/disktab on vax)

[David Brownlee <abs%netbsd.org@localhost>]

On 2 July 2012 00:01, Dave McGuire <mcguire%neurotica.com@localhost> wrote:
>
>   Very true.  NetBSD is a bloated pig now compared to what it was, say,
> in the 1.x days.  It used to be SCREAMING fast.  Of course on a big
> six-core i7 machine with 32GB of RAM, it's still screaming fast.  Twenty
> years from now, it'll likely be a bloated pig on that six-core i7.
>
>   The difference is important, though: That consumer-grade six-core i7
> machine will most definitely not be functional in twenty years, while I
> know of quite a few VAX-11/750s (~30 years old) that are still running
> just fine.  That was one of NetBSD's earliest supported systems, and the
> VERY first one, I believe, (Ragge?) for NetBSD/vax.
>
>   Let us not be too quick to de-support for the sake of de-supporting.
> The maintenance and testing overhead is minimal.  The latter can be ZERO
> if we put it on the users of, say, VAX-11/750s, to do the testing on
> those machines and report bugs, preferably with patches. (I will, once I
> get my 11/750 reassembled)

We know that more recent gcc is significantly slower as it does a lot
more work and uses a lot more memory (for very little apparent benefit
certainly on vax).

If more recent versions of NetBSD are also slower then there are three
obvious (somewhat related candidates).

- gcc code generation - should be possible to test by building a older
kernel with a recent compiler and vica-versa

- kernel size - obviously less space for userland results in a less
happy system :) Stripping down a recent kernel and adding unused
drivers to an earlier, or even adding an option to restrict the amount
of usable memory should allow testing of this

- code paths - maybe there are updates to the VM system which are
function call heavy and vax unfriendly. If the first two quick tests
do not reveal anything then its down to compiling a profiling kernel
:)

It may even be a combination of the above, but its quite likely that
one of them is a bigger factor than the others.

It would be wonderful if someone with a vax and some spare time could
try investigating these. I already have a selection of small but
random vax hacking on my plate (sysinst improvements, fixing up the
MSCP probing and increasing MAXPARTITIONS to 16 come to mind).

Come on, this month is Retrochallenge 2012 (
http://retrochallenge.org/ ), so now is a perfect excuse to spend some
time poking around with your beloven VAXen :)