Re: [Firebird-devel] FB 2.1 64bit and memory usage ??

[Alex P. <pes...@ma...>]

On Thursday 26 July 2007 14:13, Vlad Horsun wrote:
> > > > I know various db "vendors" support direct I/O as a db option
> > > > on Linux, using the current O_DIRECT implementation, but they
> > > > had to be careful in their code to avoid certain O_DIRECT
> > > > kernel bugs and race conditions.  For example, it seems mixing
> > > > O_DIRECT and non-O_DIRECT reads and writes on the same file
> > > > simultaneously may result in stale data reads or writes. The
> > > > workaround: don't do that!
> > >
> > >     posix_fadvise free from this drawback and not restrict us to use
> > > aligned memory buffers, right ?
> >
> > But lucks one more important support - direct I/O from/to user space.
>
>     If i understand correctly what Linus said about O_DIRECT implementation
> details - there are no direct I/O from/to user space. It anyway must be
> coherent with cache state. I may be wrong.

This is from 'man open':
       O_DIRECT
Try  to  minimize  cache  effects of the I/O to and from this file.  In 
general this will degrade performance, but it is useful in special 
situations, such  as  when  applications  do  their  own caching.  File I/O 
is done directly to/from user space buffers.  The I/O is synchronous, i.e., 
at the completion of a read(2) or write(2), data is guaranteed  to  have  
been  transferred. Under Linux  2.4 transfer sizes, and the alignment of user 
buffer and file offset must all be multiples of the logical block size of the 
file system. Under Linux 2.6 alignment  to  512-byte  boundaries suffices.

>     Anyway - cost of context switch and page copy is far less than cost of
> direct access to disk, isn't is ?

But if we can avoid them, why not?

> > I suggest we begin with O_DIRECT, and only in case it has serious
> > problems try with posix_fadvise().
>
>     Ok. In unix.cpp\PIO_force_write there are code i don't understant
> completely.
>
> Please explain :
>
>     why there are no call of fcntl( F_GETFL) ?

Hmmm... looks like it will be useful to do it.

>     why for "hpux" platform used "union fcntlun" while i can't find it on
>         http://docs.hp.com
>         (fcntl described at http://docs.hp.com/en/B2355-60130/fcntl.2.html)
>
>     I've attached diff with proposed fix, may you take a look at it ?

OK from F_GETFL pov, but do not want to modify hpux blindly. May be it does 
not match docs? This code was unmodied since 1.5, which has hpux port, which 
works.

>
> > This is even more important taking into an account that
> > 2.4 kernels do not support posix_fadvise().
>
>     "Do not support" is :
> a) not implemented but entrypoint exists
> or
> b) entrypoint is missed
> ?
>
>     If (a) - i think we can live with it

Yes and no. People who work with firebird under really high loads noticed that 
CS works absolutely fine with 2.4, but has problems with 2.6. Quick test (far 
not final result) showed that kernels work slightly differenly with SYSV 
semaphores. Therefore it's rather desired to have implementation fully 
operational for 2.4 too. O_DIRECT is present and implemented in both.