On 2005-11-19 simonb@wasabisystems.com wrote:
> Just as a simple test, I added some instrumentation to the sbmips port
> to count what we do when we come in to cpu_intr().  These figures are
> for booting to multiuser then building tcsh in pkgsrc:
>
> 	evcnt type 1: cpu_intr hard-only = 120263
> 	evcnt type 1: cpu_intr soft-only = 240193
> 	evcnt type 1: cpu_intr hard-soft = 102
> 	evcnt type 1: cpu_intr none = 93
>
> Interesting that we get nearly twice as many software interrupts as
> hardware interrupts, and so few of both together at the same time.
> Also, we came in to cpu_intr() a few times with ipending == 0(!).

  Hmm...  I've also wondered how often a soft interrupt schedules itself
while running.  In the current code, the new softintr would be run in the
initial interrupt and then a new interrupt would happen with nothing to do
except clear the interrupt.  The _clrsoftintr could be done in for each
soft interrupt separately in softintr_dispatch in an additional (sih ==
NULL) test before releasing the lock, which would also remove the need to
do splhigh in _clrsoftintr (although I see this would need some other
modifications to the current code also).

> > > Does it make sense to have _clrsoftintr() enable interrupts?  It's not
> > > quite the right name for such a function, but I guess it makes sense
> > > for it to enable interrupts.  I'm not sure whether we should rename it
> > > though (or what to rename it to).

  If it does, it should take an additional argument to be able to enable
the higher priority soft interrupt before doing the lower (the argument
could just be the new mask to set, to make it obvious what is happening).
Maybe the right thing would be to document it as being called at splhigh()
and then do an _splset() after that.  Then the initial splhigh() could be
skipped if there are no other interrupts pending or if moved as above.

  Also, IMO softintr_schedule should be a function, not a macro.  There is
no point in duplicating that kind of code.

> Yes, the remaining ports (with perhaps the exception of playstation2?)
> should be converted.  I'm actually planning to move algor in to evbmips,
> which will fix that one.  mipsco should be simple, and I'll leave hpcmips
> alone :-)

  The new vr code is easy to convert (you must be looking at the old
code).  I forgot about the tx stuff :).  I have two TX3922 machines, one
has never worked and the other has been broken since some time before 1.6
(the kernel doesn't print anything, maybe a bootloader issue).  Actually,
the hpcmips softintr code looks like a copy of the generic mips stuff...

Matthew Orgass
darkstar@city-net.com