as you
still have to pull a lot of data from disk, you still put quite a
pressure on VM subsystem, so direct I/O can still help,
But how to talk afio, star or mkisofs into that ?
I was thinking that a simple wrapper to open() which adds
O_DIRECT might be sufficient, but it turned out that this
alone is not sufficient: the buffers used by the programs
must have a certain alignment. This is not guaranteed
without modifying the way how those programs allocate
memory.
Do note that I assert that it *can* help. In particular if it eliminates
need for substantial amount of redundant page faults, most notably other
applications' working sets from being offloaded to swap partition
because of pressure on the block buffer and repeatedly requested back
during recording [with modern bloated GUI it's more than common
scenario], or some frequently used portions of block buffer from being
purged. "Frequently used" means "multiple times during recording, but
not frequent enough for raging data stream not to repeatedly kick it
out." As was pointed out by Bill if you want *guaranteed* success with
direct I/O, you have to complement your code with some asynchronism,
e.g. you at least want to partially undertake the block buffer role and
perform pre-fetch [and pre-open per Bill's suggestion]. Once again,
growisofs attempts to take advantage of direct I/O for "image"
recordings. "Attempts" means that it passes the O_DIRECT flag to the
kernel and aligns buffers, but I can't give any guarantees that some
particular kernel actually respects the flag. Test it, provide feedback...
On a side note it should also be noted that in particular Linux
requirements for alignment are not really reasonable. Minimal alignment
required by DMA controller, cache line size to be specific, should
suffice, but they've chosen to insist on block or sector alignment. A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
