garrett_damore@tadpole.com wrote:

> How about the following rewrite?  I've not tested it yet, but I'm a
> little concerned about the potential implications of calling hardclock
> repeatedly to "catch up" lost interrupts.  Especially as it effects ntp
> and timecounters.  I'd like to hear opinions on the matter.

I have no idea. I'd like to hear opinions of timecounter guys :-)

> I also added an evcnt for missed clock interrupts.
> 
> struct evcnt mips_int5_missed_evcnt =
>     EVCNT_INITIALIZER(EVCNT_TYPE_INTR, NULL, "mips", "missed int 5");

Yeah, I wonder how many interrupts are actually lost.

>     if (__predict_false(lost > 0)) {
>         next_cp0_clk_intr = new_cnt + curcpu()->ci_cycles_per_hz;

This should be "new_cnt + delta" to keep intervals precisely?

>         mips3_cp0_compare_write(next_cp0_clk_intr);
>         for (; lost > 0; lost--) {
>             hardclock(cfp);
>             mips_int5_evcnt.ev_count++;

hardclock(&cp) and mips_int5_missed_evcnt.ev_count?

>         }
>     }

It's probably better to control hardclock(9) except last call
not to call spllowersoftclock(9) by tweaking clockframe:
---
      if (__predict_false(lost > 0)) {
          int sr;
          next_cp0_clk_intr = new_cnt + delta;
          mips3_cp0_compare_write(next_cp0_clk_intr);
          sr = cf.sr;
          cf.sr &= ~MIPS_SR_INT_IE;
          for (; lost > 0; lost--) {
              hardclock(&cf);
              mips_int5_missed_evcnt.ev_count++;
          }
          cf.sr = sr;
      }
---
But I'd appreciate any comments from interrupt gurus.

---
Izumi Tsutsui