[Simh] vax idle for NetBSD

[Mark Pizzolato]

On Tuesday, December 11, 2018 at 2:12 AM, David Brownlee wrote:
> On Sun, 9 Dec 2018 at 09:42, Mark Pizzolato <Mark at infocomm.com> wrote:
> >
> > Well, when I followed the directions you pointed out, I did see what you
> > had reported.  A little deeper observation strongly suggested that the
> > OS execution flow that happens on NetBSD/VAX during idling had changed
> > from how things were working when I had worked through how to get things
> > well behaved idling under simh.
> >
> > I haven't yet had the time to look closely at the OS code to determine
> > what exactly was happening.  If you're seeing things OK now, maybe, there
> > is some sort of garbage collection activity going on, which runs for a while
> > and then somehow eventually stabilizes to the known idle execution
> > pattern.
> >
> > NetBSD is the fundamental exception for operating systems running under
> > simh due to the fact that it is still an actively developed and evolving
> > operating system.  As a result, the idle detection pattern will always have
> > to evolve along with the evolving OS.
> 
> That also cuts both ways (but in a good way :) - because it is still
> under active development it is reasonable to tweak the code to work
> better under simh (other ports like amd64, aarch64 and mips are
> adjusted all the time to work better under qemu), so if there is a
> better way for NetBSD to tag the idle loop, lets make it so :)
> 
> For anyone interested the current logic has:
> 
>         int ipl = mfpr(PR_IPL);
>         mtpr(1, PR_IPL);
>         mtpr(ipl, PR_IPL);
> 
> Which looks to have been there since 2012 - see
> https://nxr.netbsd.org/xref/src/sys/arch/vax/include/cpu.h?r=1.102#162

That was exactly the adjustment that I had suggested back in 2012 and 
thus enabled simh idling for NetBSD.

Meanwhile, something else has changed relatively recently that doesn't 
seem to actually execute this code when the system starts.  Specifically, 
I just observed:
  1) Boot NetBSD 8.0
  2) Boot took 100 seconds to get to a "login: " prompt.
  3) I would normally expect that the system was pretty much idle at this point and the 100 seconds would have exceeded the 20 second calibration window the idle code needs to have elapsed before the system actually idles.
  4) The system ran for another 80 seconds before idling actually kicked in.

I have no idea what the system was doing during this 80 second period, but that is not how things worked when the code above was initially added to the NetBSD kernel.

It is good that eventually the above code is engaged, so we don't really need to change anything else, but it would be interesting to understand what the system is actually doing...

- Mark