Re: Extended Prefetching using Asynchronous IO - proposal and patch
От | Claudio Freire |
---|---|
Тема | Re: Extended Prefetching using Asynchronous IO - proposal and patch |
Дата | |
Msg-id | CAGTBQpbGkepET4EnA7vLrS8DJFvh1yJKo=WiQKyHFC8CktzCkA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Extended Prefetching using Asynchronous IO - proposal and patch (John Lumby <johnlumby@hotmail.com>) |
Ответы |
Re: Extended Prefetching using Asynchronous IO - proposal
and patch
|
Список | pgsql-hackers |
On Thu, May 29, 2014 at 6:53 PM, John Lumby <johnlumby@hotmail.com> wrote: > Well, as mentioned earlier, it is not broken. Whether it is efficient > I am not sure. > I have looked at the mutex in aio_suspend that you mentioned and I am not > quite convinced that, if caller is not the original aio_read process, > it renders the suspend() into an instant timeout. I will see if I can > verify that. > Where are you (Claudio) seeing 10us? fd.c, in FileCompleteaio, sets timeout to: my_timeout.tv_sec = 0; my_timeout.tv_nsec = 10000; Which is 10k ns, which is 10 us. It loops 256 times at most, so it's polling 256 times with a 10 us timeout. Sounds wasteful. I'd: 1) If it's the same process, wait for the full timeout (no looping). If you have to loop (EAGAIN or EINTR - which I just noticed you don't check for), that's ok. 2) If it's not, just fall through, don't wait, issue the I/O. The kernel will merge the requests.
В списке pgsql-hackers по дате отправления: