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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Extended Prefetching using Asynchronous IO - proposal and patch
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: Extended Prefetching using Asynchronous IO - proposal and patch