Re: performance: use pread instead of lseek+read

Поиск
Список
Период
Сортировка
От Manfred Spraul
Тема Re: performance: use pread instead of lseek+read
Дата
Msg-id 3E5A941E.3060901@colorfullife.com
обсуждение исходный текст
Ответ на Re: performance: use pread instead of lseek+read  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: performance: use pread instead of lseek+read  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches
Tom Lane wrote:

>Manfred Spraul <manfred@colorfullife.com> writes:
>
>
>>What about removing lseek entirely and using the p{read,write}?
>>
>>
>
>Portability.
>
>$ man pread
>No manual entry for pread.
>
Which OS? google finds manpages for Tru64 4.0, HP UX 11i, solaris 8, aix 4.3
Linux has it since 2.2, FreeBSD at least since 4.0, it's even listed in
the SVR-4 emulation of FreeBSD.

>$
>
>It seems unlikely to me that eliminating lseek on some platforms would
>be worth the hassle of maintaining two code paths.  lseek is mighty
>cheap as system calls go.
>
It was considered expensive enough to write a syscall avoidance layer
that caches the file pointer and skips lseek if fpos==offset. A kernel
must perform quite a lot of parameter validation and synchronization -
think about a multithreaded app where close and lseek could race.

>
>
>>Attached is a patch vs the cvs tree.
>>It seems to work - 7.3.2 with the patch applied passes the regression
>>
>>
>
>Can you measure any performance benefit?
>
>
What would be an interesting benchmark?
If you want a microbenchmark: lseek+read(,,8192) is around 10% slower
than pread(,,,8192) with hot cpu caches on my Celeron Mobile Laptop.
Linux-2.4.20.

Read-ahead is impossible to answer without looking at the sources. Linux
does readahead, actually read is implemented as pread(,,,file->f_pos).

--
    Manfred


В списке pgsql-patches по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: performance: use pread instead of lseek+read
Следующее
От: Tom Lane
Дата:
Сообщение: Re: performance: use pread instead of lseek+read