Greg Stark <st...@mit.edu> writes:
> 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().
Hmm. The only thing you could find out is which CFI call was reporting
the long delay, not what the path of control in between had been. If
the long computation had been down inside some function that's no longer
active, this wouldn't help much to track it down. Still, it'd be better
than no data at all.
> 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.
I'm afraid you're being too optimistic about that. What I'd think about
is just adding an extra call to reset the delay-time counter after each
such syscall, rather than having two kinds of CFI.
> Obviously this wouldn't run all the time.
Yeah, it would increase the overhead of CFI by orders of magnitude,
so you wouldn't even want to think about building a production version
that way. But it might be a useful testing option.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
