On Thu, 13 Nov 1997 00:41:41 +0100 (MET)
    Paul Kranenburg <pk@cs.few.eur.nl>

>So, if splstatclock() never lowers the processor priority, then this
>scheme can be safely implemented. A quick inventory shows that the
>following ports already do this:

	[snip]

>I don't know what these ports do:
>
>       mips

Current sys/arch/mips based ports don't have have a profiling clock
separate from the time-of-day periodic interrupt. They just use the
RTC for statclock.  So we always have

		spl(bio,net,tty,imp} <= splclock
					splclock = splstatclock 
					splstatclock <= splhigh

In fact, except for the 3MIN-chassis models (5000/1{20,25,33,50},
where all spl levels are splhigh() (please don't ask) we have

		spl(bio,net,tty,imp} <  splclock
					splclock = splstatclock
					splstatclock < splhigh

The mips the splhigh() implementation just turns off the master
interrupt enable.  No other spl(9) levels are used on mips, as of yet.

So, no, unless the MI kernel code already calls splstatclock() while
at sphigh(), I don't think that mips splstatclock() ever lowers the
priority. (Even that wouldn't show up due to the splhigh() implementation.)


There's work in progress to implement pmax SPLs by reprogramming the
pmax baseboard ioctl asic's interrupt mask.  I don't think that would
change any of the above, since RTC interrupts bypass the ioctl asic
and go directly to a dedicated CPU interrupt-reuqest pin.

At some point i'd like to investigate using the mips3 on-chip counter
as an splstatclock() source. On mips3 cpus, that's hardwired to a
specific, dedicated CPU interrupt-request line, so it shouldn't be a problem.

I'e also experimented with using framebuffer vertical-retrace
interrupts as an splstatclock() source; fitting that into splsched()
is up to me.

I'd even consider making splstatclock be splhigh on mips ports, if
it's *absolutely* necessary to fix this Sparc performance bug, as long
as it doesn't materially worsen mips SCC reliability or NTP stability.
I don't think that's required, though.