Re: dvd+rw-tools update [6.0, DVD-R DL]
Bill Davidsen <davidsen@tmr.com> wrote:
> >O_DIRECT is no standard and it seems that it is just a reimplementation of the
> >very old DG/UX idea of O_DG_UNBUFFERED.
> >
> >
>
> The idea of doing unbuffered i/o is hardly that young, I believe you
> will trace it back to MULTICS and GECOS in the late 60's. IIRC that was
> done when the buffer was alligned and size to allow it, not by explicit
> user request. Having the user set a flag to request that behaviour came
> later, and I'm unsure of the portability, since there is a POSIX call to
> get the sized and aligned buffer allocated. At least for discussion
> portability is not the issue regarding performance on a single o/s type.
Without a proof for equivalence, I would asume that what you mention here
if unbuffered I/O at device level and not at file level.
The fact that Linux Linux failed to implement effifient unbufered I/O at device
level for a long time (and not does in a way that does not look UNIX like) is
just a cause if the implementation in Linux.
> >Note that what you get with this feature is less than what you get from a
> >decent VM & buffer subsystem.
> >
> >
> It's hard to imagine how an i/o to a system buffer, followed by a copy
> to a possibly misaligned user bufffer is going to be faster that i/o to
> a user buffer which is sized and aligned to allow transfer of an integer
> number of sectors. I hear what you say, but looking at the physics I
> have to think the measurement is wrong or the direct i/o is slowed by
> delays in the o/s.
Unaligned bufferes do not have much effect on the I/O speed except when you use
hardware (DMA) to do copies. Even then, a utility like star that offers
buffers aligned at a 512 byte grid is sufficient.
Most speed improvements result from avoiding I/O and this is something that
works with deceltly buffered I/O.
> For a real compare you need to test Solaris vs. Linux on the same
> hardware (I did not say or mean identical hardware, but SAME hardware),
> and test O_DIRECT vs. normal system buffered.
I did not test O_DIRECT because I believe it is not worth testing after the
experiences with DG/UX, but star is notiable faster if you boot the same
hardware with Solaris instead of Linux.
> >When I added O_DG_UNBUFFERED support into star 11 years ago, it turned out that
> >DG/UX with O_DG_UNBUFFERED was still _much_ slower than reading from a standard
> >fd on Solaris.
> >
>
> That's also not terribly relevant to the performance in the same o/s and
> hardware. I'm sure you're correct, but how does it apply to the topic?
> There is no question that in Linux doing O_DIRECT will improve the
> performance of programs using system buffers.
People who only live in a Linux based world may think this way. The rest of
us knows that it is counter productive to use such features:
- It would be better to educate the Linux people how to improve their
buffering strategies.
- Code that includes a lot of platform specific exceptions tends to
become unmaintainable.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: