More idle thoughts
От
Greg Stark
Тема
More idle thoughts
Дата
Msg-id
407d949e1003261159p329ea1c5p562bff208f1ae904@mail.gmail.com
Список
Дерево обсуждения
More idle thoughts Greg Stark <stark@mit.edu>
Re: More idle thoughts Simon Riggs <simon@2ndQuadrant.com>
Re: More idle thoughts Tom Lane <tgl@sss.pgh.pa.us>
Re: More idle thoughts Simon Riggs <simon@2ndQuadrant.com>
Re: More idle thoughts Tom Lane <tgl@sss.pgh.pa.us>
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
В списке pgsql-hackers по дате отправления