On Wed, Aug 17, 2022 at 11:42:50AM -0500, Scott Cheloha wrote: > On Wed, Aug 17, 2022 at 01:30:29PM +0000, Visa Hankala wrote: > > On Tue, Aug 09, 2022 at 09:54:02AM -0500, Scott Cheloha wrote: > > > On Tue, Aug 09, 2022 at 02:03:31PM +0000, Visa Hankala wrote: > > > > On Mon, Aug 08, 2022 at 02:52:37AM -0500, Scott Cheloha wrote: > > > > > One thing I'm still uncertain about is how glxclk fits into the > > > > > loongson picture. It's an interrupt clock that runs hardclock() and > > > > > statclock(), but the code doesn't do any logical masking, so I don't > > > > > know whether or not I need to adjust anything in that code or account > > > > > for it at all. If there's no logical masking there's no deferral, so > > > > > it would never call need to call md_triggerclock() from splx(9). > > > > > > > > I think the masking of glxclk interrupts are handled by the ISA > > > > interrupt code. > > > > > > Do those machines not have Coprocessor 0? If they do, why would you > > > prefer glxclk over CP0? > > > > > > > The patch misses md_triggerclock definition in mips64_machdep.c. > > > > > > Whoops, forgot that file. Fuller patch below. > > > > > > > I have put this to the test on the mips64 ports builder machines. > > > > The machines completed a build with this patch without problems. > > I tested with the debug counters removed from cp0_trigger_int5(). > > > > OK visa@ > > Thank you for testing! > > There was a loongson portion to this patch. Is this OK on loongson or > just octeon?
OK for both. > Also, what did the debug counters look like when you yanked them? If > cp0_raise_miss was non-zero I will double the initial offset to 32 > cycles. After about 92 hours, one machine showed cp0_raise_calls=622486 and another 695892. cp0_raise_miss was zero on both of them. On two other machines I had forgotten to allow ddb access from console and could not check the values. The current offset is good enough.
