More idle thoughts

From: Greg Stark <stark(at)mit(dot)edu>
To: "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: More idle thoughts
Date: 2010-03-26 18:59:11
Message-ID: 407d949e1003261159p329ea1c5p562bff208f1ae904@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-03-26 19:06:17 Re: TODO list updates
Previous Message Robert Haas 2010-03-26 18:53:24 Re: TODO list updates