The Linux kernel had a big push to reduce latency, and one of the
tricks they did was they replaced the usual interrupt points with a
call which noted how long it had been since the last interrupt point.
It occurs to me we could do the same for CHECK_FOR_INTERRUPTS() by
conditionally having it call a function which calls gettimeofday and
compares with the previous timestamp received at the last CFI().
I think the only gotcha would be at CHECK_FOR_INTERRUPTS() calls which
occur after a syscall that an actual interrupt would interrupt. They
might show a long wait even though an actual interrupt would trigger
them right away -- the two that come to mind are reading from the
client and blocking on a semaphore. So I think we would need to add a
parameter to indicate if that's the case for a given call-site. I
think it would be easy to know what value to put there because I think
we always do a CFI() immediately after such syscalls but I'm not 100%
sure that's the case.
Obviously this wouldn't run all the time. I'm not even sure it should
run on the build farm because I think doing an extra syscall at these
places might mask timing bugs by synchronizing the bus in a lot of
places. But even a few build farm animals might uncover places where
we don't respond to C-c or hold up the sinval messages etc.
It also doesn't replace our current method of responding to user
complaints -- many if not all of them are relatively subtle cases
where the user is doing something unusual to create a loop that
doesn't normally occur. But we won't know that unless we try.
--
greg